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SECTION  1 


EXECUTIVE  OVERVIEW 

A.  Assessment  Requirements 

The  methods  assessment  was  performed  as  Task  4  under  the 
Manufacturing  Technologies  Special  Studies  (MTSS)  program,  at  the 
direction  and  sponsorship  of  the  Integration  Technology  Division, 
Manufacturing  Technology  Directorate,  Wright  Research  and  Development 
Center  (WRDC/MTI) .  The  task  requirement  was  to  conduct  a  top-level 
assessment  of  activity  (IDEF-0)  and  information  (IDEF-lx)  modeling 
methods  needed  to  support  overarching  enterprise  framework 
applications.  The  results,  as  presented  in  Section  4,  provide  a 
preliminary  strategic  plan,  or  blueprint,  tailored  to  the  needs  of 
related  USAF  and  industry  requirements  for  integrated  information 
modeling  capabilities.  The  plan  is  a  systematic  and  incremental 
approach  for  strategic  improvements  relative  to  enterprise  framework 
applications . 

B .  Background 

The  generation  and  control  of  enterprise  operations  information 
and  related  activities  associated  with  procurement,  logistics, 
engineering,  production,  product  development,  product 
deployment/service,  and  business  development  have  evolved  as  critical 
elements  in  the  economics  of  computer  integrated  manufacturing. 
Computer  applications  have  introduced  new  and  costly  complexities  on 
how  we  control  and  integrate  the  same  enterprise  information  within 
different  operating  environments:  local  (single  site),  wide  area 
(multi-site) ,  global  (multi-national) .  Often,  different  computer 
systems  and  operating  standards  are  employed  in  the  same  operating 
environment,  making  it  costly  and  cumbersome  to  communicate  within  a 
single  operating  organization,  not  to  mention  the  deployment, 
servicing,  and  supplier  environments  which  also  must  be  considered. 

In  order  to  support  the  defense  industrial  base,  which  has  strong 
influence  and  implications  in  the  commercial  sector,  it  is  extremely 
critical  that  adequate  methods,  tools,  standards,  and  life  cycle 
strategies  be  established  on  a  global  basis  for  modeling,  analysis, 
and  integration  support  of  total  enterprise  operations  and  product 
description  development  and  application. 

Activity  and  information  modeling  methods  and  tools  have  proven 
their  value  in  improving  Enterprise  operations,  for  example  by 
identifying  cost-saving  process  improvements,  enabling  Total  Quality 
Management  (TQM)  implementations,  providing  more  timely  manufacturing 
and  financial  data,  etc.  However,  these  methods  have  not  been 
optimized  in  terms  of  scope,  economics,  simplification,  and 
automation  tools.  A  broad  based  set  of  complementary  modeling  and 
analysis  methods  and  tools  are  needed  to  conduct  effective  top-down 
analyses  of  activities  on  a  global  architecture  basis,  as  well  as  an 
optimized  set  of  modeling  methods  and  tools  to  support  bottom-up 
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design.  The  effectiveness  of  the  IDEF  Methods  has  proven  valuable 
many  times  over  for  activity  and  information  modeling  on  a  company- 
by-company  approach  for  application.  Based  on  assessment  information 
available  today,  there  is  sufficient  justification  to  support  using 
the  existing  activity  and  information  modeling  methods  as  the  basis 
for  enhancements  and  improvements  that  will  address  the  needs  of 
today's  global  enterprise  operations. 


C.  Highlights  of  Accomplishments 

This  section  provides  a  synopsis  of  key  information  sources  that 
served  as  milestone  inputs  for  achieving  assessment  results.  Many 
additional  contributions  were  provided  by  equally  important  sources 
as  reflected  throughout  the  report. 

C.l  Active  Framework  Initiatives:  CIM-OSA 

In  the  area  of  active  framework  initiatives,  the  Task  4  Team 
focused  on  the  European  "Computer  Integrated  Manufacturing  -  Open 
System  Architecture"  (CIM-OSA)  Framework  as  being  the  broadest  scope 
as  well  as  the  most  advanced  information  source  for  Task  4  purposes 

C.1.1  Discussions  with  ESPRIT's  Program  Manager  for  CIM-OSA 

In  May  1990,  following  an  overview  presentation  on  the  CIM-OSA 
Program  at  the  IDEF-UG  Conference,  Task  4  Team  Members  met  with  the 
CIM-OSA  Program  Manager.  The  purpose  of  the  meeting  was  to  focus  on 
a  working  relationship  that  would  support  an  assessment  of  IDEF 
applications  and  enhancements  needed  to  support  broad  based 
enterprise  frameworks  on  the  same  scale  addressed  by  the  CIM-OSA 
framework.  The  meeting  resulted  in  a  course  of  action  that  would 
lead  to  complimentary  initiatives.  The  course  of  action  focused  on 
needed  coordination  activities  leading  to  a  three-day  workship  with 
IBM  representatives  familiar  with  the  CIM-OSA  Framework  and 
Guidelines.  The  workship  was  intended  to  provide  an  understanding  of 
the  CIM-OSA  Framework  as  well  as  the  modeling  needs  that  could  be  met 
by  the  current  IDEF  Method  and  to  establish  recommendations  that 
reflect  needed  enhancements  to  the  IDEF  Modeling  methods  to  support  a 
large  precentage  of  the  CIM-OSA  needs. 

C. 1 .2  IBM  Meeting 

Following  a  series  of  Air  Force  and  IBM  coordination  activities, 
a  three-day  meeting  with  IBM  in  Rochester,  Minnesota  was  established. 
IBM  is  a  participant  in  the  CIM-OSA  effort  in  Europe,  and  this  was  an 
opportunity  for  the  Task  4  Team  to  meet  with  personnel  having  in- 
depth  technical  knowledge  of  CIM-OSA.  During  the  workshop,  IBM 
conducted  a  review  of  each  Framework  Section  and  the  philosophy  for 
its  use.  This  was  followed  by  the  viewing  of  a  PC  Storyboard  of  the 
CIM-OSA  Project  and  a  walkthrough  discussion  of  the  38-step  CIM-OSA 
Life  Cycle  approach. 
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Each  of  the  38  steps  of  the  CIM-OSA  Lifecycle  was  examined  by 
the  Task  4  Team  at  the  Minnesota  meeting,  and  the  applicability  of 
the  IDEF  methodology  to  support  these  steps  was  assessed.  The  IDEF 
method  was  mapped  to  the  requirements,  design,  and  implementation 
phases  of  the  CIM-OSA  life  cycle  steps.  The  assessment  determined 
that  IDEF  partially  or  wholly  supports  more  than  50%  of  the  steps,  as 
reflected  in  Figure 
1-1 . 


CIM-OSA  Phase 

CIM-OSA 

Step 

Support 
by  IDEF 

Not  Supported 
by  IDEF 

Requirements 

20 

15 

4  Behavior 

1  Integration 

Design 

9 

5 

4  Resources 

Implementation 

9 

N/A 

Figure  1-1  IDEF  Coverage  of  CIM-OSA  Lifecycle  Steps 

The  results  of  the  mapping  exercise  show  a  high  degree  of  IDEF 
support  for  the  requirements  and  design  phases.  Furthermore,  a 
limited  number  of  enhancements  will  significantly  improve  the 
opportunity  to  apply  the  methodology  on  a  much  broader  basis. 

C  .  2  IDEF  U .  G . 

The  IDEF  User  Group  provided  an  important  second  source  of 
methodology  assessment  input.  It  is  the  only  group  comprised 
entirely  of  IDEF-interest  organizations,  including  users,  tool 
vendors,  and  consultants.  It  therefore  provides  a  key  source  of 
application  needs  and  experience  with  the  IDEF  methods  for  the  Task  4 
assessment  effort. 

A  meeting  of  the  IDEF  User  Group  was  held  during  the  Task  4 
period  of  performance.  The  Task  4  Team  took  advantage  of  this 
opportunity  to  survey  the  attendees  at  the  conference  regarding  th 
IDEF  needs  and  recommendations.  A  special  evening  session  was  hel 
during  the  meeting;  about  30  participants  from  different 
organizations  attended  the  session.  The  session  resulted  in  several 
specific  recommendations,  which  have  been  incorporated  into  the  Task 
4  Strategic  Plan. 

C.3  Needs  of  the  CALS  Community 

The  Task  4  Team  also  assessed  the  needs  of  the  Computer  Aided 
Acquisition  and  Logistic  Support  (CALS)  community  as  a  source  of 
important  future  IDEF  support  needs.  In  a  meeting  at  the  DoD  CALS 
Office,  it  was  recommended  that  the  major  need  from  the  CALS 
perspective  is  to  ensure  compatability  with  the  EXPRESS  language. 
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Since  CALS  relies  upon  both  IDEFlx  and  EXPRESS,  and  since  there  is 
significant  overlap  in  capabilities,  the  CALS  community  would  be  best 
served  by  establishing  integration  links  between  IDEFlx  and  EXPRESS 
to  reduce  re-dundancy  and  to  imporve  compatibility  between  the  two 
modeling  methods. 

C.4  Survey  of  User  Needs 

The  IDEF  user  community  at  large  provided  the  Task  4  Team  with 
the  final  major  source  of  assessment  input.  To  pursue  this  area,  a 
survey  of  knowledgeable  industry,  academic,  and  Government 
individuals  was  conducted  to  determine  their  present  analysis  methods 
needs,  their  vision  of  their  future  needs,  and  the  "lessons  learned" 
from  IDEF  usage  to  date.  The  survey  is  a  critical  factor  in 
identifying  real  needs. 

The  survey  format  closely  followed  the  format  used  in  performing 
industrial  sector  assessments.  Appendix  A  presents  the  survey 
process,  the  questions  asked,  the  names  of  the  organizations  surveyed 
(the  Source  List),  and  the  responses. 

D.  Assessment  and  Recommendations 


The  Task  4  Team  assessed  the  inputs  from  the  above  and  other 
sources  to  identify  and  define  key  issues  associated  with  methodology 
enhancements  and  complementary  supplements  without  jeopardizing  the 
basic  IDEF  Methods  for  activity  and  information  modeling.  (These 
methods  have  proven  to  be  extremely  valuable  in  evolving  a  total 
enterprise  framework  in  the  context  of  a  single  system.) 


As  a  result  of  the  assessment,  a  set  of  recommendations  was 
developed  with  primary  focus  on  a  global  framework,  specifically  CIM- 
OSA,  with  secondary  focus  on  individual  enterprise  levels  of 
application.  The  recommendations  will  be  needed  in  the  near  future 
to  keep  the  IDEF  methods  viable  and  the  "method  of  choice"  of 
Framework  and  Architecture  developers  and  users  (CIM-OSA,  SEMATECH, 
CALS,  etc.).  The  individual  recommendations  and  the  kinds  of 
benefits  provided  by  each,  are  presented  below. 


Recommendation 


Benefits 


1  Integrate  the  ICAM-developed  System  Development  Reduce  modeling  cost/time 

Methodology  (SDM)  and  the  IDEF-UG-developed  Broaden  application 

IDEF  Framework  with  the  IDEF  Suite  of  Methods. 


2  Enrich  the  IDEF  Methods  such  that  models  can  be 
executable  during  requirements  and  design. 


Improve  model  utility 

Increase  ROI  due  to  latent  capabilities 


3  Construct  IDEFlx  models  of  key  CIM-OSA  templates  Strengthen  Framework  role 

to  support  the  application  of  IDEF  on  a  global  basis  Provide  structured  focus 

with  a  structured  focus. 
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4  Establish  the  integration  links  for  IDEFO  and  IDEFI/lx  Encourage  users 

methods  to  allow  the  development  of  activity  and  More  cost-effective  IDEF  use 

information  models  that  are  integratable. 

5  Establish  procedures,  concepts,  and  tools  that  will  Reduce  modeling  cost/time> 

sustain  IDEF  Enterprise  models  as  reusable,  with  a  Leverage  insight  from  existing  models 

method  for  implementing  configuration  management. 

6  Supplement  the  existing  IDEF  methods  with  syntax  that  Expand  IDEF  application  area 

will  extend  IDEF  models  to  support  design-level  development.  Increase  IDEF  utility  for  AF  Operations 

7  Extend  IDEFO  and  IDEFI/lx  for  expanded  usability.  Current  Achieve  more  useful  models 
descriptions  of  the  IDEF  Method  lack  insight  for  multiple  Leverage  insight  from  modeling 

experience 

applications  such  as:  TQM,  concurrent  engineering, 
cost  benefits,  needs  and  requirements  integration,  and  a 
host  of  related  beneficial  applications. 

8  Add  IDEFO,  IDEFI/lx  Rule  Sets  for  addressing  behavioral  Provide  a  structured  Framework  role 

issues.  This  was  a  key  area  of  need  associated  with  Frame-  Increase  IDEF  ROI 

works  on  the  level  represented  by  the  CIM-OSA  concept. 

9  Add  IDEFO  and  IDEFI/lx  Method  Rule  Sets  to  assure  Leverage  modeling  experience 

proper  development  and  application  of  IDEF  Methods.  Reduce  wasted  modeling  costs 

Expand  industry  receptivity  to  IDEF 

10  Establish  integration  links  for  IDEFI/lx  and  EXPRESS  Support  CALS/PDES 

so  that  both  techniques  can  be  used  in  a  complimentary  Reduce  redundant  effort 
fashion. 

1 1  Provide  standards  and  guidelines  for  the  use  and  Increase  usage  benefits 

application  of  IDEF.  This  is  a  major  void  in  the  current  Reduce  redundant  and  wasted  efforts 

method  description  that  leads  to  mis-application,  bad 

results,  and  bad  press. 

The  Task  4  Strategic  Plan,  Section  4,  contains  expanded  detail 
for  each  recommendation.  This  is  accompanied  by  a  simple,  systematic 
road  map  that  provides  an  incremental  development  structure  to  allow 
for  optimized  and  flexible  implementation  of  improvements  with 
acceptable  returns  on  related  investments. 


SECTION  2 


INDUSTRY  DIRECTIONS 

To  achieve  the  required  level  of  CIM  capabilities  for  the  U.S. 
and  other  countries  to  remain  competitive,  industry  lines  must  be 
crossed  and  technology  must  be  transferred  and  shared.  Both  Japanese 
and  European  industrial  communities  have  initiated  frameworks, 
methods,  and  technologies  to  make  use  of  the  available  CIM 
capabilities  in  the  most  effective  and  efficient  ways.  The  U.S.  seems 
to  have  lagged  behind  in  this  endeavor,  and  must  pull  the  industrial 
forces  within  the  country  together  in  order  for  all  to  remain 
competitive . 

A.  Frameworks 

Major  obstacles  exist  in  the  enterprise  environment  that  are 
causing  less  than  an  optimum  performance  in  the  areas  of  information 
cost  and  information  handling.  The  generation,  management,  and 
control  of  information  and  technology  associated  with  product 
development,  use,  and  servicing  has  evolved  as  a  critical  element  in 
the  development  of  integrated  production  systems.  With  the 
application  of  the  computer  in  the  production  environment,  new  and 
costly  complexities  have  surfaced  regarding  control  and  integration 
of  information  at  different  enterprise  locations  through  the  product 
development  and  product  deployment  phases. 

The  same  issues  have  surfaced  in  both  the  Japanese  and  European 
industrial  communities  and  both  have  major  initiatives  underway  to 
address  this  problem.  The  U.  S.  is  considered  to  be  lagging  in  an 
equivalent  effort.  The  issues  that  must  be  addressed  to  make 
integrated  systems  happen  within  the  U.  S.  consist  of;  1) 
establishing  an  enterprise  integration  framework  (EIF) ,  2)  achieving 
a  national  consensus  to  promote  and  establish  the  framework  for  a 
broad  community  of  industries,  and  3)  developing  common  methods, 
standards,  and  specifications  that  will  allow  systems,  based  on  a 
consensus  architecture  and  method,  to  be  integratable . 

Under  the  EIF  Program,  the  various  frameworks  currently  under 
development  were  categorized  in  a  helpful  way.  The  categories  are 
summarized  in  Figure  2-1,  along  with  an  example  of  a  currently  active 
framework  effort  for  each  category. 
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Examples 


CIM-OSA 


CALS 


GM-C4 


NADSARP 


IMIP  Phase  1 


ISO-OSI 


Figure  2-1  shows  that  the  CIM-OSA  Framework  has  the  largest 
scope,  covering  multi-industries,  conglomerates  of  firms,  and  several 
technologies.  Because  of  this  broad  scope,  the  EIF  Program  stated 
that  the  CIM-OSA  Framework  has  the  potential  to  be  the  "backbone" 
toward  which  they  recommend  future  efforts  be  directed. 

B .  Methods 

The  methods  addressed  in  the  Task  4  effort  were  mainly  the  IDEF 
and  CIM-OSA  activity  and  information  modeling  methods.  Other 
periphery  or  complimentary  methods  and/or  tools  were  addressed  in  the 
assessment  but  did  not  receive  the  detailed  analysis  that  IDEF  and 
CIM-OSA  received. 

Japanese  framework  initiatives  are  being  developed  to  improve 
data  integration  within  Japanese-owned  companies  located  throughout 
the  world.  Very  little  information  has  been  released  about  the 
Japanese  developments  currently  underway.  While  conducting  the  DoD 
Assessment  of  Japanese  Manufacturing  Technology1,  it  was  observed 
that  most  Japanese  companies  address  enterprise  integration  on  a  cell 
level  within  the  typical  plant  hierarchy  (plant,  center,  cell, 
station,  process) . 

While  studying  the  operations  of  two  of  the  companies  visited, 
it  was  noted  that  IDEF  activity  and  information  models  were  being 
employed  for  analysis  of  future  developments  on  a  multi-plant  level 
of  world-wide  operations.  One  enterprise  presented  a  ten  year  multi¬ 
facility  strategy  as  a  single  set  of  integrated  systems.  This 
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Global 
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Trading  Partner 
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Technology 
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Scope 


Figure  2-1  Categories  of  Frameworks  (EIF) 


1  Ref:  Findings  of  the  U.S.  Department  of  Defense  Technology  Assessment  Team  on  Japanese 
Manufacturing  Technology,  Final  Report,  June  1989. 
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represented  a  broad  framework  concept  with  methodologies,  including 
IDEF,  to  support  the  analysis  and  development  for  enterprise 
integrated  information  systems.  Detailed  information  on  the  IDEF 
application  or  the  framework  strategy  was  not  made  available  by  the 
Japanese  company.  This  point  emphasizes  that  other  framework-like 
initiatives,  using  IDEF  Methods,  are  being  employed  by  U.S. 
competitors . 

The  European  Strategic  Programme  for  Research  and  Development  of 
Information  Technology  (ESPRIT)  is  leading  the  development  of 
activity  and  information  modeling  and  simulation  methodologies 
through  the  European  Computer  Integrated  Manufacturing  Architecture 
(AMICE)  program  —  a  consortium  of  21  companies  from  7  European 
countries.  The  AMICE  project.  Computer  Integrated  Manufacturing  - 
Open  System  Architecture  (CIM-OSA) ,  is  a  method  that  is  based  upon 
templates  and  living  models  developed  to  assure  an  Open  System 
Architecture  approach  to  CIM. 

In  the  U.S.,  the  EIF  Program  has  recommended  the  adoption  of  the 
CIM-OSA  Framework  as  a  baseline.  This  step  will  ensure  a  common 
frame  of  reference  and  facilitate  communications  and  joint 
development.  Steps  are  already  under  way  to  formalize  an  agreement 
between  the  CIM-OSA  organization  and  the  MANTECH  office  of  the  Air 
Force . 

From  the  surveys  returned  under  the  Assessment  effort,  U.S. 
industry  has  expressed  the  opinion  that  the  future  will  see  methods 
applied  at  the  enterprise  level,  whereas  they  see  present  methods 
being  used  in  a  more  limited  scope.  They  have  asked  that  methods  be 
expanded  to  cover  the  enterprise  level,  wherever  necessary,  and  that 
care  be  taken  to  see  that  methods  are  carefully  integrated. 

They  anticipate  an  integrated  set  of  methods  and  tools  that  can 
be  applied  to  understand,  model,  and  control  enterprises.  Enterprise 
analysis  methods  and  tools  will  provide  a  means  of  analyzing 
performance  through  various  forms  of  simulation.  Standard  frameworks 
will  be  used  to  identify  when,  how,  and  for  what  purpose  these  new 
methods  should  be  properly  applied. 

"Object-Oriented"  thinking  appears  to  be  anticipated  as  the  new 
way  of  thinking  about  systems,  according  to  the  survey  results. 
Therefore,  whatever  methods  extensions  are  developed  should  take  this 
influence  into  account  so  as  not  to  become  outmoded. 


C.  Technologies 

The  technology  currently  supporting  the  use  of  IDEF  is  designed 
to  support  both  textual  and  graphic  input  of  diagrams  and  to  check 
for  consistency  and  syntax  errors.  Model  structures  can  be  retained 
and  manipulated,  and  support  for  the  Reader/ Author  critique  of 
diagrams  is  available.  About  a  dozen  COTS  (Commercial  Of f-the-Shelf ) 
tools  are  available  in  the  U.S.  and  Europe. 
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In  general,  integration  between  various  IDEF  methods  is  not 
supported.  Each  IDEE’  method  is  independent  of  the  others,  and  data 
from  one  IDEF  method  must  be  manually  extracted  and  input  to  another 
IDEF  method.  Data  dictionaries  have  been  successfully  integrated 
with  the  IDEF  methods  and  this  feature  is  readily  available  in  the 
support  toolset . 

Computer-Aided  Software  Engineering  (CASE)  technology  has 
expanding  and  will  soon  include  the  Requirements  Analysis  level.  One 
vendor  of  CASE  tools  has  already  included  SADT  as  an  optional  tool  in 
the  CASE  toolset.  However,  most  CASE  technology  vendors  appear  to  be 
ready  to  develop  new  methods  for  Requirements  Analysis.  This  is 
either  due  to  lack  of  readily  available  information  and  publicity  on 
IDEF  (most  are  unaware  of  its  existence  and  potential) ,  or  it  stems 
from  a  feeling  that  more  elaborate  syntax  with  additional  computer- 
oriented  constructs  are  needed  to  capture  the  fine  detail  of  the 
requirements.  In  the  latter  instance,  CASE  technology  is  focused 
more  on  the  Design  Requirements  of  the  software,  whereas  IDEF  is 
focused  on  the  earlier,  System-Level  requirements. 

At  the  System  Requirements  level,  communications  between  users 
and  developers  are  key,  and  therefore  favors  the  IDEF  methods .  At 
the  Software  Requirements  level,  just  prior  to  the  Design  phase,  the 
key  is  fine  definition  and  traceability  of  detailed  software 
requirements  information.  The  future  hope  for  the  "marriage"  of  the 
two  levels  of  requirements  lies  in  a  focused  effort  to  define  the 
interfaces  and  develop  tools  that  export/import  the  information 
between  the  two  levels. 

The  "Object-Oriented"  approach  is  a  technology  that  is  gaining 
favor  world-wide,  and  must  be  taken  into  consideration  as  it  will 
affect  IDEF.  The  survey  of  users  clearly  indicated  that  they  expect 
the  future  of  methods  to  lie  in  the  "Object-Oriented"  way  of 
thinking.  At  this  time,  the  "Object-Oriented"  technology  appears  to 
be  part  of  the  Computer  Science  domain,  and  therefore  is  not 
perceived  to  be  germain  to  the  System  Requirements  domain  of  IDEF. 
However,  any  future  extensions  of  IDEF  methods  must  take  this  new 
technology  into  account  and  plan  for  the  interfaces  between  IDEF  and 
the  new  "Object-Oriented"  requirements  and  design  technology 
approaches  as  they  become  more  popular  and  widespread. 

Local  Area  Network  (LAN)  technology  is  another  factor  in  the 
future  considerations  for  IDEF.  The  use  of  LAN  networks  of  small  and 
medium  sized  computers  with  intelligent  workstations  has  been  gaining 
favor  over  the  large  mainframe/terminal  approach.  The  IDEF  tool 
vendors  appeared  after  this  evolution  had  begun,  and  are  solidly 
aligned  with  the  LAN  technology  side  of  the  computer  industry. 

There  are  numerous  modeling  packages  that  have  been  used  for 
IDEF  methodology  graphical  and  textual  modeling.  Many  of  these 
packages  were  developed  specifically  for  IDEF  modeling,  while  others 
were  developed  as  methodology  independent  packages  but  can  be  used 
for  various  IDEF  methodology  modeling  functions.  Each  of  these  tools 
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has  been  developed  with  a  different  interpretation  of  what  an  IDEF 
model  consists  of  and  the  rules  for  creating  and  manipulating  model 
elements,  due  to  the  lack  of  a  clear  and  precise  description  of  the 
IDEF  methods.  In  general,  those  modeling  packages  developed  by 
workers  who  were  involved  with  the  original  development  of  the  IDEF 
methodologies  tend  to  follow  the  original  intent  more  closely  than 
those  packages  developed  by  less  experienced  IDEF  practitioners. 

Listed  below  is  a  representative  sample,  in  alphabetical  order, 
of  the  many  automated  modeling  packages  available  for  IDEF  modeling 
A  one  to  two  sentence  description  accompanies  each  identified 
package,  indicating  its  uses  and/or  attributes. 

•  AIO,  by  Knowledge  Based  Systems 

This  is  an  interactive,  textual-input  (as 
opposed  to  graphical  input)  PC-based  tool  for 
structured  analysis,  using  hierarchical  function 
modeling  based  upon  IDEFO . 

•  AI2,  by  Knowledge  Based  Systems 

This  is  an  integrated  PC-based  toolset  for 
information  analysis,  that  incorporates  the 
IDEFO,  1,  and  lx  methodologies. 

•  AutoFAS,  by  Bernier  &  Associates 

This  tool  offers  capabilities  for  generation  of 
IDEFO  and  IDEF1  models,  simulation, 
organizational  impact  analysis,  financial  impact 
assessment,  prioritization  of  needs,  and  related 
graphical  and  textual  documentation. 

•  AUTOSADT,  by  Triune  Systems 

This  tool  offers  graphic  diagram  drawing  and 
model  retention  for  the  SADT  superset  of  IDEFO. 

It  operates  on  the  Macintosh  platform. 

•  CBAM,  by  Control  Data  Corporation 

This  tool  uses  the  models  developed  in  IDEFO  to 
allow  for  cross-function  cost  analysis. 

•  COINS,  by  Eclectic  Solutions 

This  tool  is  a  PC-based  graphical  IDEFO  tool 
with  data  dictionary,  that  supports  Kit 
processing  and  diagram/model  manipulation 
features.  VAX  and  other  platform  versions  are 
also  available. 

•  DAFNE,  by  Italsiel 

This  a  PC-oriented  CASE  tool  with  the  SADT 
superset  of  IDEFO  integrated  with  the  toolset 
provided  by  the  Excellerator  product  of  Index 
Technology.  It  features  full  database  modeling 
capability,  report  generation,  model 


manipulation,  etc.  Support  is  available  in 
Europe  only. 

DEFIN.IT,  by  Solion  Systems 

This  tool  is  methodology-independent,  but  has 
the  capability  to  support  IDEF1  modeling.  It 
uses  ORACLE  database  support,  and  has  graphical 
and  textual  capabilities. 

DEFT/DFD  and  DEFT/ERD,  by  DEFT 

This  CASE  tool  runs  on  numerous  platforms  and  is 
methodology  independent.  The  graphical  and 
report  formats  can  be  used  to  model  and  to 
analyze  models  created  using  the  IDEFlx 
methodology . 

Design/IDEF  (for  PC  and  Macintosh),  by  MetaSoftware 
This  tool  is  IDEFO  and  IDEF1  specific.  It 
offers  text  and  graphic  modeling  capapbilities 
in  support  of  the  IDEF  methodologies . 

Design/CPN,  by  MetaSoftware 

This  tool  uses  the  Colored  Petri  Nets  converted 
from  Design/IDEF  to  simulate  the  model  (s) . 

The  Developer,  by  ASIST  Technologies 

This  is  PC-based  tool  for  information  modeling. 

It  is  a  CASE  tool  that  is  methodology 
independent,  but  is  customizable  through  the  use 
of  The  Customizer. 

ERWIN,  by  Logicworks 

An  IDEFlx  tool  for  the  IBM-PC,  for  conceptual 
modeling  and  database  design.  Uses  Windows  3.0 
in  a  graphical  environment  as  well  as  SQL 
generation . 

FLEXIS,  by  Savoir 

This  is  a  CASE  tool  and  is  not  IDEF  specific, 
and  does  not  follow  the  IDEF  rules.  It  can  be 
used  for  simulation. 

IDEF/LEVERAGE,  by  DACOM 

This  is  a  mainframe-based  tool  that  supports 
both  IDEFO  and  IDEFlx  activity  and  data 
modeling.  It  offers  merge  capabilities  to 
create  a  composite  model  and  transforms  the  DBMS 
model  into  SQL  statements  to  assist  in 
implementaion .  IDEF  methodology  reports  are 
available . 

Personal  IDEF/LEVERAGE,  by  DACOM 

This  tool  is  similar  to  IDEF/LEVERAGE  but  is  PC 
based  and  does  not  have  the  merge  capabilities. 


It  is  specific  for  single  model  development  and 
for  import  into  IDEF/LEVERAGE  for  analysis. 

•  IDEFine-0,  by  Wizdom  Systems 

This  package  runs  on  PC  or  SUN  platforms.  It 
offers  both  IDEFO  textual  and  graphical  modeling 
capabilities  with  the  associated  report 
generation  capabilities. 

•  IDEFine-lx,  by  Wizdom  Systems 

This  package  runs  on  PC  (MS/DOS)  or  SUN  (UNIX) 
platforms.  It  offers  both  IDEFlx  textual  and 
graphical  modeling  capabilities  with  the 
associated  report  generation  capabilities. 

•  IDEFcost,  '  ”  Wizdom  Systems 

This  to<.  .  uses  the  models  developed  in  IDEFine-0 
to  allow  for  cross-function  cost  analysis 

•  IDEFGlossary ,  by  Wizdom  Systems 

This  is  the  Glossary  function  in  support  of  the 
IDEFine-0  and  IDEFine-1  automated  IDEF  toolset. 

•  The  Integrator,  by  ASYST  Technologies 

This  tool  is  a  storage  and  display  tool  for 
information  related  to  information  systems 
development  objects. 

•  Mode IP ro,  by  DACOM 

This  tool  is  Microsoft  Windows-based  and  is 
DACOM’ s  IDEF  methodology  modeling  graphics 
package.  The  tool  offers  two-way  communication 
with  IDEF/LEVERAGE  for  graphical  representation 
and  model  creation  prior  to  or  after 
normalization,  integration,  and/or  analysis. 

•  RETA,  by  SofTech 

A  requirements  evaluation,  traceability,  and 
analysis  tool  for  use  with  a  set  of  completed 
IDEFO  and  IDEFlx  models.  Links  requirements 
between  IDEFO  and  IDEFlx  models  and  supports  on¬ 
line  analysis  of  the  effects  of  system  changes. 

•  Software  Backplane,  by  Atherton  Technology 

This  tool  is  a  CASE  tool  and  is  not  IDEF 
specific.  It  supports  the  integration  of 
various  modeling  methodologies,  both  function 
and  information  models,  and  allows  for 
modification  of  report  format. 

There  are  numerous  CASE  tools  that,  with  or  without 
modification,  can  be  used  to  automate  the  modeling  required  by  the 
IDEF  methodologies.  The  extent  of  their  usefulness  to  IDEF  modeling 


1  2 


relies  on  the  users  and  modelers  knowledge  of  the  IDEF  methodologies' 
rules  and  requirements. 


SECTION  3 


ASSESSMENT  MISSION 

The  mission  of  the  Task  4  team  "Assessment”  effort  is  shown  in 
Figure  3-1. 


Figure  3-1  The  Assessment  Mission 

The  various  active  framework  initiatives  form  the  basis  of  the 
assessment  process.  Driven  by  these  framework  efforts,  the  required 
capabilities  that  enable  IDEF  to  support  the  framework  are  assessed. 
Along  with  industry  needs  in  general,  as  solicited  from  the 
industrial  user  community,  the  IDEF  Framework  and  user  support 
picture  are  defined.  The  required  enhancements  and  recommendations 
to  enable  IDEF  to  achieve  its  potential  in  support  of  these  needs  and 
to  ensure  the  IDEF  legacy,  are  then  defined  as  the  output  of  the 
assessment  task. 

The  Assessment  Mission  scope  of  effort  is  derived  from  the 
Integration  Technology  Division's  (ITD)  mission  statement,  however  it 
is  narrower  in  scope.  By  stating  the  Assessment  Mission  as  a  subset 
of  the  ITD  mission,  we  see  how  it  falls  naturally  within  the  domain 
of  the  ITD. 

In  the  following  Assessment  Mission  statement,  the  original  ITD 
statement  is  presented,  with  wording  changes  included  within  "{}" 
braces,  to  indicate  where  the  narrowing  of  scope  is  invoked  to  match 
the  mission  to  the  Assessment  effort  of  the  Task  4  team. 

The  (Methods  Assessment  Project  of  the/  Integration  Technology 

Division  (ITD)  will  provide  an  (assessment  of  the  present  status 

and  recommendations  regarding  an/  Air  Force  focus  for  the 


articulation,  development ,  and  implementation  of  processes , 
methodologies,  and  standards  for  information  and  technology 
integration  across  the  entire  product  life  cycle.  (The  Assessment 
Project  will  recommend  a  strategic  plan  with  which/  ITD  will 
facilitate  the  transition  of  life-cycle  requirements  into  the 
design  and  manufacture  of  weapons  systems  resultant  in  (1)  reduced 
life-cycle  costs,  (2)  reduced  concept-to-deployment  time,  (3) 
improved  product  quality,  and  (4)  increased  Defense  Industrial 
Base  production  and  support  flexibility .  In  addition,  (the 
Assessment  Project  of)  ITD  is  responsible  for  (recommending/ 
applied  research  to  advance  the  state-of-the-art  for  integration 
technologies  and  to  expedite  the  transition  of  those  component 
technologies  to  the  Air  Force  Logistics  Centers,  the  Defense 
Industrial  Base,  and  other  Air  Force  organizations . 

To  summarize,  the  Assessment  Mission  is  to  assess  the  present 
state-of-the-art  in  information  and  technology  integration,  and  to 
recommend  steps  to  facilitate  transition  of  these  integration 
approaches  into  the  design  and  manufacture  of  weapons  systems  to 
reduce  costs,  reduce  concept-to-deployment  time,  improve  quality,  and 
improve  flexibility.  The  Assessment  Mission  results  will  also 
include  recommendations  for  applied  research  toward  these  ends. 


SECTION  4 


STRATEGIC  PLAN 

A.  Assessment  Results 

The  information-gathering  phase  of  the  Task  4  effort  resulted  in 
a  list  of  needs  for  IDEF  methodology  enhancements.  To  translate  the 
needs  into  solutions  to  those  needs,  a  Strategic  Plan  was  developed 
by  the  Task  4  Team,  using  the  Assessment  Mission  to  guide  the  plan 
development.  This  section  presents  the  Strategic  Plan,  beginning 
with  the  process  of  deriving  specific  recommended  future  tasks  from 
the  list  of  needs,  and  then  laying  out  those  tasks  in  the  form  of  a 
roadmap  for  carrying  them  out. 

Figure  4-1  summarizes  the  problems  identified  from  the  frame¬ 
works,  surveys,  and  IDEF  User  Group  sources,  translates  each  problem 
into  a  set  of  needs,  requirements,  tools  and  methods  involved,  and 
lists  solutions.  Section  B,  below,  translates  these  solutions  into 
the  specific  task  recommendations  needed  to  achieve  the  desired 
solutions . 
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Figure  4-1.  General  Matrix  Mapping  of  Problems  to  Solutions 
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B. 


Recommendations 


The  right-most  column  of  Figure  4-1  shows  the  Recommendations 
designed  to  address  each  Problem  identified  in  the  left-most  column. 
There  are  eleven  recommendations  in  all  resulting  from  the  Assessment 
effort.  In  the  remainder  of  this  section,  each  of  the  eleven 
recommendations  is  presented  in  more  detail. 

B.l  Presentation  Format  and  Content 

Eleven  specific  recommendations  have  resulted  from  the  Task  4 
findings.  These  are  presented  below  in  order  of  recognition, 
followed  by  a  prioritization  matrix  and  a  suggested  Roadmap  for 
taking  action  to  implement  each  recommendation. 

Each  of  the  eleven  recommendations  is  presented  in  the  form  of  a 
Presentation  Slide,  followed  by  further  textual  detail.  Each  slide 
has  the  same  format,  as  shown  in  Figure  4-2. 


RECOMMENDATION  NUMBER  ([number]) 

[Name  of  the  Recommendation] 

PRIORITY:  [1,  2,  or  3] 

NEEDS  ADDRESSED:  [Needs  identified  during  survey] 

BENEFITS  TO  THE  AIR  FORCE:  [Why  the  Air  Force  should  support  the 

recommended  effort] 

INVESTMENT  STRATEGY:  [Recommended  support] 

WHAT  Should  be  Done:  [The  goals  and  objectives] 

HOW  It  Should  be  Done:  [Specific  recommended  steps] 

OUTPUTS:  [Results  produced  (documents,  software,  etc.)] 


Figure  4-2.  Presentation  Format  for  Recommendations 

The  goal  of  using  this  stylized  presentation  format  is  to  ensure 
coverage  of  the  key  issues  associated  with  each  recommendation,  and 
to  facilitate  understanding  by  the  audience. 


B.2  Specific  Recommendations 


In  this  section,  each  of  the  eleven  recommendations  is  presented 
in  the  format  described  in  Section  B.l. 


RECOMMENDATION  NUMBER  (1) 

INTEGRATE  ICAM/SDM  AND  FRAMEWORK  INTO  THE  IDEF  SUITE 

PRIORITY:  1.  Prerequisite 

NEEDS  ADDRESSED:  (a)  Provide  Guidance  in  the  Use  of  IDEF 

(b)  Relate  Methods  Use  to  Frameworks 

(c)  Establish  Full  Lifecycle  Role  for  IDEF 

BENEFITS  TO  THE  AIR  FORCE:  (a)  Reduce  IDEF  Modeling  Cost  and  Time 

(b)  Expand  Opportunity  for  Additional 
Benefits  and  Broader  Applications 

INVESTMENT  STRATEGY :  Support  Funded  Co-Development  with  IDEF 

User  Group 

WHAT  Should  be  Done: 

Adopt  standard  Lifecycle  definitions  and  flow  descriptions  for 
best  established  uses  of  IDEF  within  the  SDM  Guidelines .  In¬ 
clude  Lifecycle  phase  and  step  training  in  standard  IDEF 
courses.  Complete  the  IDEF  Framework.  Then  use  Lifecycle 
definitions  and  flow  descriptions  to  identify  Framework  links  to 
methods,  and  relate  Framework  cell  interfaces  via  Lifecycle 
usage  details. 

HOW  It  Should  be  Done: 

Merge  SDM,  Framework,  and  IDEF  into  a  common  specification.  Use 
the  IDEF  User  Group  as  a  forum  to  gain  consensus,  to  adopt 
standard  Lifecycles,  and  to  document  the  Lifecycle  role  of  IDEF 
in  standard  training  courses  and  manuals.  Gather  sample  models 
and  usage  scenarios  relating  to  individual  Lifecycles,  to 
provide  guidance  to  IDEF  users. 

OUTPUTS:  (1)  Combined  SDM  &  IDEF  Spec;  (2)  Sample  Model  and  Usage 

Scenario  Doc;  (3)  Executive  Overview  &  Brochures 


Figure  4-2.1  Recommendation  "1" 


RECOMMENDATION  NUMBER  (2) 


ENRICH  IDEF  MODELS  TO  BE  EXECUTABLE 

PRIORITY:  3.  Required 

NEEDS  ADDRESSED:  (a)  Support  for  Frameworks  such  as  CIM-OSA 

(b)  Extend  Usability  to  Better  Support 
Implementation  Efforts 

BENEFITS  TO  THE  AIR  FORCE:  (a)  Improve  IDEF  Utility 

(b)  Greater  Return  on  IDEF  Investment 
due  to  Latent  Capabilities 

INVESTMENT  STRATEGY:  Fund  Development  of  IDEF  Execution 

Constructs  that  Supplement  the  Existing 
IDEF  Specification 

WHAT  Should  be  Done: 

Provide  the  IDEF  Language  enhancements  and  procedures  necessary 
to  allow  IDEF  models  to  become  "executable  specifications", 
especially  at  the  Design  Level.  Provide  the  ability  to 
understand  AS-IS  and  test  alternative  TO-BE  scenarios  to 
evaluate  design  alternatives  and  tradeoffs.  Relate  the  IDEF 
modeling  and  simulation  bodies  of  knowledge. 

HOW  It  Should  be  Done:  (Related  to  Recommendations  4,  6,  and  8) 

In  conjunction  with  4,  6,  and  8,  analyze  existing  IDEF  methods 
and  tools,  and  develop  supplemental  specifications  to:  1)  add 
constructs  necessary  for  simulation,  2)  specify  kinds  and 
properties  of  simulations,  3)  define  outputs  of  simulation 
activities,  and  4)  map  to  existing  simulation  tools.  Present 
features  to  the  IDEF  User  Group  and  get  consensus. 

OUTPUTS:  (1)  Addendum  to  the  IDEF  Spec;  (2)  Prototype 

(3)  Machine  Executable  Example 


Figure  4-2.2  Recommendation  "2" 


RECOMMENDATION  NUMBER  (3) 

CONSTRUCT  IDEF1X  MODELS  OF  CIM-OSA  TEMPLATES  AND  IDEF  CONSTRUCTS 
PRIORITY:  2.  Critical 

NEEDS  ADDRESSED:  (a)  Permit  Communication  w/CIM-OSA 

(b)  Illustrate  IDEFlx  Utility  to  CIM-OSA 

(c)  Provide  Focused  Areas  for  IDEF  Applications 

BENEFITS  TO  THE  AIR  FORCE:  (a)  Establishes  Stronger  Role  and 

Attraction  to  IDEF  for 
Framework  Applications 
(b)  Provides  a  Structured  Focus 

INVESTMENT  STRATEGY:  Support  a  Joint  IDEF/CIM-OSA  Effort 

WHAT  Should  be  Done: 

Get  templates  of  constructs  from  CIM-OSA  and  define  the  elements 
of  each  template  and  the  relationships  between  the  templates, 
using  the  IDEFlx  method.  Develop  a  meta-model  of  the  IDEF 
constructs . 

HOW  It  Should  be  Done : 

Finalize  the  agreement  of  cooperation  between  the  ManTech  Office 
and  CIM-OSA,  and  then  organize  a  joint  project  in  which  an 
IDEFlx  expert  works  with  a  CIM-OSA  expert  to  define  a  model  of 
the  templates  as  well  as  a  meta-model  of  IDEF  constructs. 

Extend  the  meta-model  as  other  recommendations  extend  IDEF 
modeling  techniques.  Distribute  the  resulting  models  and  gain 
IDEF  User  Group  consensus. 

OUTPUTS:  (1)  IDEFlx  Model  of  CIM-OSA  Templates  and  meta-model  of 

IDEF  constructs;  (2)  Set  of  detailed  technical  recommendations 
for  improvements  to  both  IDEFs . 


Figure  4-2.3  Recommendation  "3'' 
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RECOMMENDATION  NUMBER  (4) 


INTEGRATE  IDEFO  AND  IDEF1X 

PRIORITY:  2.  Critical 

NEEDS  ADDRESSED:  (a)  Reduce  Redundant  Data  Collection,  Effort; 

Enhance  Accuracy,  Completeness,  Consisten¬ 
cy,  Uniformity 

(b)  Long-Standing  User  Group  Request 

(c)  Provide  Single  Model  Relationship  for 

Function  and  Info 

BENEFITS  TO  THE  AIR  FORCE:  (a)  Encourage  IDEF  Use  by  Demonstra¬ 

ting  Support  for  Requests  from 
Users 

(b)  More  Cost-Effective  IDEF  Usage 

INVESTMENT  STRATEGY:  Fund  an  Integration  Methods  &  Spec 

Development  Contract  with  Academic, 
Practitioner,  Framework,  User,  and  Vendor 
Technical  Input 

WHAT  Should  be  Done : 

Develop  an  Integration  Approach  and  set  of  corresponding 
specifications  for  the  IDEFO  and  IDEFlx  methods.  The  approach 
must:  1)  allow  integration  at  both  the  requirements  and  design 

levels,  2)  permit  IDEFO  and  IDEFlx  models  to  be  developed  in  any 
order,  including  concurrently,  and  3)  include  how  to  integrate, 
which  completeness  and  consistency  checks  to  make,  and  how  to 
use  these  checks.  Continued  use  of  IDEF  as  in  the  past  must  be 
permitted . 

HOW  It  Should  be  Done : 

Contract  with  a  company  or  coalition  with  demonstrated  IDEFO  and 
IDEFlx  credentials  to  develop  the  method,  including  graphics 
syntax,  semantics,  and  pragmatics,  to  provide  the  needed 
integration  of  the  content  of  both  models.  Use  the  experience 
of  the  users  and  Tool  Vendors  to  provide,  as  a  minimum,  the 
benefits  demonstrated  on  past  modeling  efforts  which  related 
IDEFO  and  IDEFlx  by  such  techniques  as  data  dictionaries. 

OUTPUTS:  (1)  Addendum  to  the  IDEF  Spec  document;  (2)  Meta-model  of 

IDEFO,  IDEFlx,  and  the  Integration  Constructs 


Figure  4-2.4  Recommendation  "4" 


RECOMMENDATION  NUMBER  (5) 


ADD  CONCEPTS  &  TOOLS  FOR  REUSE  &  CONFIGURATION  MANAGEMENT 

PRIORITY:  3.  Required 

NEEDS  ADDRESSED:  (a)  Permit  ’’Living  Model”  Use  of  IDEF 

Rather  than  One-Shot  Analysis 

(b)  Facilitate  New  Model  Startup 

(c)  Establish  Maintenance  &  Update  as  an 

On-going  Process 

BENEFITS  TO  THE  AIR  FORCE:  (a)  Reduce  Modeling  Cost  and  Time 

(b)  Leverage  Insight  from  Existing 
Models 

INVESTMENT  STRATEGY:  Support  a  Funded  Co-Development  with  the 

IDEF  User  Group 

WHAT  Should  be  Done: 

Use  existing  body  of  reusability  research  and  configuration 
management  knowhow  to  adopt  IDEF  standards  for  both 
capabilities.  Encourage  tool  vendors  to  comply  with  these 
standards .  Develop  a  meta-model  based  on  the  IDEF  Framework 
which  includes  configuration  definition,  model  check-out /check¬ 
in,  change  notification,  design  intent  capture,  and  usage  cross- 
reference  . 

HOW  It  Should  be  Done : 

Re-address  Project  1104  procedures  for  maintenance  &  configura¬ 
tion  control.  Charter  a  Working  Group  of  the  IDEF  User  Group  to 
investigate  and  select  features  from  available  commercial 
products.  After  adoption  by  the  IDEF  U.G.,  select  a  contractor 
to  develop  &  implement  the  meta-model  using  an  object-oriented 
DB  management  system  and  publish/demonstrate  the  results  to 
the  Air  Force  and  the  IDEF  U.G.  Establish  a  model  reuse 
facility  and  solicit  contributions. 

OUTPUTS:  (1)  Requirements  Spec;  (2)  Meta-model;  (3)  Prototype 

Reuse/CM  System 


Figure  4-2.5  Recommendation  "5" 
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RECOMMENDATION  NUMBER  (6) 

DEVELOP  DESIGN-LEVEL  SYNTAX 
PRIORITY:  2.  Critical 

NEEDS  ADDRESSED:  (a)  Provide  Design  Capabilities 

(b)  Enhance  Methods  to  Better  Support 
Implementation 

BENEFITS  TO  THE  AIR  FORCE:  (a)  Expand  IDEF  Application  Areas 

(b)  Increase  Utility  of  IDEF  for  Air 
Force  Operations 

INVESTMENT  STRATEGY:  Fund  Design  Extension  Effort 

WHAT  Should  be  Done : 

IDEF  Methods  were  originally  intended  to  support  understanding, 
needs,  requirements,  and  benefits  analysis.  Addition  of  design 
syntax  to  the  basic  IDEF  syntax  should  be  made,  to  broaden  the 
scope  of  applicability  of  IDEF  and  reduce  the  number  of 
different 

methods  that  must  be  employed.  Include  representational  power 
of 

data  flow  diagramming  and  external  and  internal  schema,  as  a 
minimum  capability. 

HOW  It  Should  be  Done : 

Contract  with  a  methods  development  organization  that  is 
familiar 

with  modern  design  methods  to  bring  IDEF  up  to  (and  beyond)  the 
capabilities  of  other  methods  or  choice  in  the  design  area.  Use 
the  IDEF  User  Group  as  a  "sounding  board"  to  gain  acceptability 
of 

features  before  implementation,  run  demos,  etc.  Define  the 
design 

constructs  as  a  superset  of  present  IDEF  so  as  to  retain  upward 
compatibility.  Factor  in  CIM-OSA  design  level  constructs  when 
available . 

OUTPUTS:  (1)  Addenda  to  the  IDEF  Specifications  (both  IDEFO  and 

IDEFlx) 


Figure  4-2.6  Recommendation  "6" 
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RECOMMENDATION  NUMBER  (7) 


EXTEND  IDEFO  AND  IDEF1X  FOR  EXPANDED  APPLICATION 


PRIORITY:  2.  Critical 

NEEDS  ADDRESSED:  (a)  Provide  “Lessons  Learned”  Benefits  from 

Usage  Experience 

(b)  Remove  Present  Usage  Limitations 

BENEFITS  TO  THE  AIR  FORCE:  (a)  Provide  More  Useful  Models 

(b)  Leverage  Insight  from  Existing 
Modeling  Experience 

INVESTMENT  STRATEGY:  Fund  an  Initiative  to  Assess  and  Implement 

Complete  Application  Understanding 

WHAT  Should  be  Done: 

Implement  recommendations  for  features  which  have  been  found  to 
be  useful  from  experienced  IDEF  user  organizations .  Include 
features  from  rival  methods  so  as  to  make  IDEF  the  "method  of 
choice” . 

HOW  It  Should  be  Done : 

Request  IDEF  User  Group  members  to  write  up  and  contribute 
selected  enhancements.  Re-visit  the  originax  SADT  and 
Information  Modeling  methods  to  consider  features  that  were 
originally  excluded  from  IDEF,  to  see  present  applicability. 

Use  the  IDEF  U.G.  to  determine  acceptability.  Evaluate 
capabilities  added  to  rival  methods  since  the  adoption  of  IDEF, 
to  see  if  similar  enhancements  should  be  made  to  IDEF.  Develop 
a  Guidelines  document,  and  update  courses  and  specs  for  adopted 
features . 

OUTPUTS:  (1)  "Guidelines  on  Usability"  Document;  (2)  Updated  Specs 

and  Course  Material 


Figure  4-2.7  Recommendation  "7" 
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RECOMMENDATION  NUMBER  (8) 


ADD  IDEFO  AND  IDEF1X  RULE  SETS  FOR  BEHAVIORAL  ASPECTS 
PRIORITY:  3.  Required 

NEEDS  ADDRESSED:  (a)  Support  for  Frameworks  such  as  CIM-OSA 

(b)  Remove  a  Recognized  IDEF  Limitation 

BENEFITS  TO  THE  AIR  FORCE:  (a)  Establish  Stronger  Role  and 

Attraction  to  IDEF  for  Framework 
Applications 

(b)  Greater  Return  on  IDEF  Investment 
INVESTMENT  STRATEGY:  Fund  a  Requirements  and  Spec  Effort 

WHAT  Should  be  Done : 

Add  rules  for  modeling  and  specification  of  behavioral  aspects 
of  an  enterprise.  Integrate  the  new  capabilities  with  the 
modeling  capability.  Make  a  meta-model  of  the  constructs,  and 
match  to  capabilities  of  object  oriented  databases. 

HOW  It  Should  be  Done : 

Fund  the  development  of  a  set  of  Templates  of  Constructs  which 
model  behavioral  aspects  of  an  enterprise.  Relate  the  resulting 
method  and  develop  examples  of  its  use  as  support  of  the  CIM-OSA 
lifecycle  steps  not  now  supported  by  IDEF.  Add  results  to  the 
IDEF  specification,  courses,  repository  of  models,  etc.  Use  the 
IDEF  User  Group  to  review  and  recommend  changes  to  the  new 
feature.  Fund  an  optional  prototype  development  effort. 

OUTPUTS:  (1)  Meta-model  of  Constructs;  (2)  Addenda  to  Design-level 

Specs;  (3)  Prototype 


Figure  4-2.8  Recommendation  "8" 
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RECOMMENDATION  NUMBER  (9) 

ADD  IDEFO  &  IDEF1X  METHOD  RULE  SETS 
PRIORITY:  3.  Required 

NEEDS  ADDRESSED:  (a)  Provide  "Lessons  Learned"  Benefits  from 

Usage  Experience 

(b)  Control  Proper  Use  of  IDEF  &  Eliminate 

Negative  Image  Caused  by  Mis-application 

BENEFITS  TO  THE  AIR  FORCE:  (a)  Leverage  Good  Modeling  Experience 

(b)  Reduce  Wasted  Modeling  Costs 

(c)  Expand  Industry  Receptivity  to  Use 

IDEF 

INVESTMENT  STRATEGY :  Support  Funded  Co-Development  with  the  IDEF 

User  Group 

WHAT  Should  be  Done: 

Develop  Usage  Rules  from  experienced  users,  to  help  guide  IDEF 
training  and  usage.  Incorporate  usage  rules  into  IDEF  training 
courses  and  other  materials.  Publicize  resulting  rule  sets  so 
as  to  inhibit  improper  IDEF  usage  under  the  name  of  "IDEF". 

HOW  It  Should  be  Done: 

Establish  a  Working  Group  task  under  the  IDEF  User  Group  to 
develop  the  Rule  Sets.  Distribute  the  draft  Rule  Sets  to  the 
full  User  Group  mailing  list  for  comment  and  recommendation. 

Use  the  IDEF  User  Group  forum  to  hold  discussion  and  vote 
adoption . 

OUTPUTS:  (1)  Method  Rule  Set  Specifications 


Figure  4-2.9  Recommendation  "9" 
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RECOMMENDATION  NUMBER  (10) 


PROVIDE  IDEF1X  AND  "EXPRESS"  INTEGRATION  LINKS 
PRIORITY:  3.  Required 

NEEDS  ADDRESSED:  (a)  Eliminate  Current  Mismatch  Problems 

(b)  Extend  Info  Modeling  Capability  to  IDEFlx 

(c)  Establish  IDEF  as  Complimentary  with 

EXPRESS 

BENEFITS  TO  THE  AIR  FORCE:  (a)  Support  CALS/PDES  Standardization 

(b)  Reduce  Redundant  Efforts 

INVESTMENT  STRATEGY:  Support  Funded  Co-Development  with  the  IDEF 

User  Group 

WHAT  Should  be  Done: 

Analyze  the  process  of  common  data  exchange  between  IDEFlx  and 
EXPRESS  to  determine  the  items  which  must  be  added  or 
streamlined  to  improve  joint  use  of  IDEF  and  EXPRESS.  Determine 
how  to  add  these  items  to  the  IDEFlx  models.  Determine  "loose" 
and  "tight"  linkage  approaches.  Coordinate  with  Recommendations 
2,  6,  and  8. 

HOW  It  Should  be  Done: 

Establish  an  IDEF-UG  Working  Group  to  study  the  problem  and 
recommend  enhanced  IDEFlx  syntax,  semantics,  and  pragmatics  to 
be 

added  to  the  standard  IDEFlx  definition.  Attain  approval  of  the 
IDEF  User  Group,  and  contract  with  a  methods  consulting 
company  or  coalition  to  complete  the  design,  documentation, 
training  materials,  etc. 

OUTPUTS:  (1)  IDEFlx-to-EXPRESS  Links;  (2)  Integration  Methods  Spec; 

(3)  EXPRESS-to-IDEFlx  Links 


Figure  4-2.10  Recommendation  "10" 
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RECOMMENDATION  NUMBER  (11) 


PROVIDE  IDEF  STANDARDS  AND  GUIDELINES 
PRIORITY:  11(a)  1.  Prerequisite;  11(b)  3.  Required 

NEEDS  ADDRESSED:  (a)  Eliminate  Misuse  and  Misunderstanding 

(b)  Expand  &  Advertise  IDEF  Capabilities 

(c)  Establish  Baseline  Standard 

(d)  Provide  Basis  for  Validation  &  Verification 

BENEFITS  TO  THE  AIR  FORCE:  (a)  Increase  Benefits  from  IDEF  Use 

(b)  Less  Redundant  &  Wasted  Effort 

INVESTMENT  STRATEGY:  Provide  Funding  for  Updating  the  Users 

Manual  into  a  Standard 

WHAT  Should  be  Done: 

Gather  specs,  procedures,  concepts/purpose/goals  statements, 
examples,  training  materials,  papers,  etc.,  to  be  used  for 
guidance  by  novice  IDEF  users.  Advertise  the  availability  of 
this  material  and  its  use  to  show  to  potential  new  IDEF  users. 
Use  as  guidance  for  new  IDEF  users  to  avoid  improper  usage  of 
the  methods.  Split  the  effort  into  two  tasks:  Use  initial  spec 
as  a  baseline  prior  to  other  enhancements  (Task  11(a)),  and 
incorporate  results  of  pursuing  the  other  recommended  tasks  as  a 
final  repository  (Task  11(b)). 

HOW  It  Should  be  Done: 

Instead  of  "Certification"  of  IDEF  trainers  and  users,  examples 
of  good  practice  should  be  gathered,  advertised,  and  used  to 
guide  application  of  the  methods.  The  IDEF  User  Group  must 
serve  as  the  central  repository  of  such  material,  as  well  as  the 
focal  point  for  publicity  and  the  source  of  authorized  IDEF 
Materials . 

OUTPUTS:  (1)  Critical  Specs  for  Initial  Baseline  (11a); 

(2)  Final  Specs  (lib) 


Figure  4-2.11  Recommendation  "11” 
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B.3  Prioritization  of  Recommendations 

The  eleven  recommendations  have  been  presented  in  order  of 
recognition.  There  is  a  natural  ordering  between  several  of  the 
recommendations,  since  in  some  cases  the  recommended  activity  uses 
the  results  of  one  of  the  other  recommended  activities.  This 
"natural  order",  plus  the  invoking  of  a  "criticality  factor"  provides 
a  recommended  sequence  in  which  to  pursue  the  recommendations . 

Figure  4-3  shows  the  "natural  ordering"  of  the  recommendations 
with  interdependencies  illustrated  by  the  f inish-to-f inish 
connections.  Note  that  Recommendation  11  (IDEF  Standards  and 
Guidelines)  is  split  into  two  tasks  —  11(a)  "Baseline  Standards"  to 
provide  the  basic  standards  and  guidelines  needed  to  pursue  the  high- 
priority  recommendations,  and  11 (b)  "Enhanced  Standards  and 
Guidelines"  to  provide  the  remainder  of  the  standards  and  guidelines 
developed  as  a  result  of  pursuing  the  recommended  tasks. 


4-3  Natural  Ordering  of  Recommendations 


Figure  4-4  summarizes  the  "criticality  factor"  for  each 
recommendation  based  upon  the  following  6  criteria: 

(a)  Maintain  1DEF  as  a  viable  tool  of  choice  for  generic  frameworks 

(b)  Establish  interfaces  to  make  IDEF  complimentary  for  use  with 
other  framework  tools 

(c)  Extend  utility  of  IDEF  to  cover  broadest  scope  framework 

(d)  Acceptability  of  enhancements  by  IDEF  User  Group 

(e)  Make  use  of  and  interface  with  emerging  technologies 

(f)  Cornerstone  prerequisite  (required  as  a  basis  for  other 
recommendations) 

In  each  case,  the  Task  4  team  ranked  each  of  the  eleven 
recommendations  as  a  1,  2,  or  3  (highest)  based  upon  each  criterion. 
Figure  4-4  summarizes  the  resulting  ranking.  Each  recommendation 
achieved  a  ranking  of  between  10  and  15.  The  priority  was  then 
assigned  based  upon  a  three-level  prioritization  scheme: 

Top  Priority:  "Prerequisite"  Ranking  15-16 

Second  Priority:  "Critical"  Ranking  13-14 

Third  Priority:  "Required"  Ranking  10-12 


SCORE:  15  11  13  15  12  1«*  ^3  12  12  10  16 


Figure  4-4  Recommendation  Ranking  Matrix 
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C.  Suggested  Roadmap 

Using  the  prioritization  resulting  from  the  application  of  the 
six  criteria,  and  taking  into  account  the  natural  precedence  of  the 
eleven  recommendations,  a  suggested  Roadmap  was  developed  (see  Figure 
4-5) ,  The  shaded  areas  at  the  beginning  of  several  of  the  roadmap 
boxes  represent  possible  "early  start  dates"  for  these  tasks.  That 
is,  there  is  no  logical  reason  that  the  effort  cannot  begin  at  the 
earliest  date  shown,  except  for  availability  of  personnel  and 
funding . 

Across  the  top  of  Figure  4-5,  a  row  of  triangles  numbered  "PI" 
through  "P5"  are  shown.  These  represent  natural  milestones  in  the 
timeline,  when  groups  of  efforts  should  be  started  or  completed. 


Task  #4  IDEF  Enhancement  Roadmap 


Figure  4-5  IDEF  Enhancement  Roadmap 
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SECTION  5 


SYNOPSIS  OF  ACCOMPLISHMENTS 


A.  IDEF  User  Group  Meeting 

A  semi-annual  IDEF  User  Group  meeting  was  held  on  May  22-24  at 
the  Washington  Plaza  Hotel,  Washington  D  The  Task  4  team  took 
advantage  of  this  opportunity  by  holding  a  special  evening  meeting  on 
Wednesday,  May  23  to  solicit  recommendations  for  IDEF  enhancements  by 
the  User  Group  members.  About  30  people  attended. 

The  meeting  began  with  an  introduction  to  the  Task  4  goals  and 
objectives,  followed  by  verbal  recommendations  from  the  floor.  At 
the  end,  a  call  was  made  for  any  User  Group  member  to  submit  his  name 
and  address  to  be  added  to  be  contacted  at  a  later  date.  Fourteen 
names  were  submitted  to  the  chairman.  These  names  were  later  added 
to  the  Source  List  to  receive  a  solicitation  package. 

The  meeting  was  organized  around  four  overhead  slides,  which 
presented  an  overview  of  Task  4,  the  specific  Task  4  objectives,  the 
planned  format  of  the  Strategic  Plan  to  be  developed,  and  a  list  of 
the  potential  contributions  from  the  User  Group  attendees.  The 
specific  slides  are  included  in  Appendix  B  "Meeting  Minutes". 

The  discussion  resulted  in  several  specific  recommendations, 
which  have  been  incorporated  into  the  Strategic  Plan  in  Section  4 
"Submitted  Recommendations",  below.  In  general,  the  recommendations 
fell  into  two  primary  categories:  1)  standardization/formalization 
needs,  and  2)  specific  syntax/semantics  needs.  The  lengthiest 
discussion  topic  was  on  training  and  experience  standards  for 
determining  who  is  and  is  not  to  be  labeled  an  "IDEF  Expert",  both 
for  developing  models  and  for  training  new  authors. 

B.  CIM-OSA  Support  Assessment 

The  primary  framework  driving  the  assessment  effort  was  CIM-OSA. 
Specific  enhancements  to  IDEF  have  resulted  from  the  team's 
investigation  of  the  CIM-OSA  needs. 

Briefly,  the  Air  Force  is  interested  in  having  IDEF  selected  to 
support  the  CIM-OSA  Framework  and  Lifecycle  developments.  The  alter¬ 
native  would  be  to  have  CIM-OSA  invest  in  new  methods  development 
which  is  incompatible  with  IDEF.  This  alternative  would  be  costly  to 
the  companies  supporting  CIM-OSA,  would  lead  to  difficulties  in 
understanding  and  using  the  results  of  CIM-OSA  in  the  U.S.,  and  would 
greatly  reduce  the  value  of  the  legacy  and  Air  Force  investment  in 
IDEF  models  such  as  the  ICAM  Generic  Model  of  Manufacturing. 

The  May  IDEF  User  Group  meeting  afforded  the  opportunity  to 
discuss  potential  cooperation  between  the  IDEF  community  and  the  CIM- 
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OSA  community.  A  representative  of  the  CIM-OSA  organization  attended 
the  IDEF  User  Group  conference  in  Washington,  and  met  with  the  IDEF 
Steering  Committee  the  evening  of  Monday,  May  22  to  explore  potential 
cooperation.  As  a  result  of  this  meeting,  the  Air  Force  sent  a 
letter  to  CIM-OSA  as  a  first  step  in  arranging  for  cooperative 
technical  efforts.  The  CIM-OSA  representative  also  remarked  that  the 
technical  papers  presented  at  the  conference  were  very  enlightening 
and  encouraging  for  potential  IDEF  use  in  his  CIM-OSA  work. 

To  better  assess  the  potential  for  IDEF  as  a  method  for  use  by 
CIM-OSA,  the  Task  4  team  requested  that  the  Air  Force  arrange  a 
technical  interchange  meeting  with  a  representative  CIM-OSA 
organization  in  the  U.S.  In  response  to  this  request,  the  Air  Force 
contacted  IBM,  and  arranged  a  two-day  meeting  in  Rochester,  Minnesota 
(see  Executive  Summary  and  Meeting  Minutes  in  Appendix  B.2,  below) . 

A  representative  from  the  IBM/Oswego  facility  also  attended,  since 
that  facility  is  also  participating  in  the  CIM-OSA  effort. 

At  the  meeting,  it  was  determined  that  there  is  significant 
potential  for  IDEF  support  of  CIM-OSA.  By  going  through  the  CIM-OSA 
Lifecycle  at  length,  it  was  determined  that  the  majority  of  the 
Lifecycle  steps  can  be  at  least  partially  supported  by  IDEF. 

Specific  IDEF  enhancements  were  noted  as  a  result  of  the  technical 
assessment.  However,  several  detailed  technical  questions  rem.-,  i  nod 
that  could  not  be  answered  by  the  Rochester/Owego  IBM  staff. 

It  was  decided,  as  part  of  the  new  cooperation  being  arranged  by 
the  Air  Force,  that  the  Task  4  Group  conduct  an  on-site  visit  to  CIM- 
OSA  at  their  European  facility,  to  clarify  these  technical  issues  and 
to  further  pursue  the  IDEF  support  issues.  Later,  at  the  July  24 
Task  4  meeting,  word  was  received  via  the  Air  Force  that  CIM-OSA  had 
decided  not  to  permit  the  planned  European  visit. 

CIM-OSA  stated  that  this  decision  is  not  intended  to  convey  lack 
of  interest,  but  is  a  result  of  CIM-OSA  concerns  regarding 
proprietary  disclosure  of  information  funded  by  the  CIM-OSA 
organizations.  Further  investigation  of  these  issues  is  being 
pursued,  and  it  is  anticipated  that  the  technical  interchange  meeting 
will  take  place  at  a  later  date,  once  the  legalities,  ground  rules, 
and  participating  organization  agreements  are  arranged. 

C.  Survey  of  Needs 

C.l  Source  List  and  Assignments 

At  the  initial  meeting,  a  "Source  List"  of  29  names  and 
organizations  to  be  contacted  by  the  Task  4  group  was  developed. 
Later,  the  list  was  expanded  to  41  names  through  submittals  at  the 
IDEF  User  Group  meeting,  and  by  the  Task  4  team  members. 

The  final  list  of  Sources  is  included  in  Appendix  A.  The  names 
on  the  list  through  29  were  contacted  individually  before  being  sent 
a  solicitation  letter  and  list  of  questions.  The  remaining  names  (30 
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through  41)  had  requested  that  they  be  added  to  the  Source  List; 
four  of  these  were  contacted  individually  by  telephone,  and  the 
remainder  received  a  mailing  without  prior  telephone  discussion,  due 
to  schedule  limitations. 

C.2  Cover  Letter  and  Generic  Question  List 

The  Task  4  team  decided  that  a  standard  Cover  Letter  be 
developed  for  use  with  mailings  to  the  Source  List  names.  This 
letter  was  developed,  reviewed  and  modified  by  the  Air  Force,  and 
distributed  to  the  Task  4  team  members.  A  copy  of  this  letter,  along 
with  the  final  set  of  generic  questions  is  included  in  Appendix  A. 

Note  that  the  "Generic  Questions"  are  intended  as  a  starting 
point  and  thought -provoker .  People  on  the  Sources  List  were  told 
that  they  should  feel  free  to  add  recommendations  and  needs  not 
related  to  specific  question  list  items,  and  not  to  bother  answering 
questions  that  are  not  related  to  their  individual  IDEF  usage 
experience . 

C.3  Summary  of  Survey  Results 

The  results  of  the  solicitation  were  very  encouraging. 
Significant  benefits  are  being  achieved  through  the  use  of  IDEF,  and 
there  is  enthusiastic  support  for  continued  support  and  extension  of 
the  IDEF  methods  among  the  user  community. 

The  recommended  enhancements  to  IDEF  resulting  from  the  survey 
are  compatible  with  the  CIM-OSA  findings;  therefore,  the  Task  4  Team 
is  confident  that  their  recommendations  are  well-founded  and  backed 
by  real  industry  needs. 

D.  Meetings 

There  were  four  Task  4  Team  Meetings  over  the  contract’s  Period 
of  Performance,  as  well  as  special  presentations  to  the  IDEF  User 
Group  Steering  Committee  and  the  IDEF  User  Group  itself  (special 
evening  session)  : 

(1)  Kickoff  Organizational  Meeting  (May  16) 

(2)  IDEF  User  Group  Session  (May  22-24) 

(3)  Rochester  CIM-OSA  Meeting  (June  20-22) 

(4)  Working  Session  (July  23) 

(5)  IDEF  Steering  Committee  Presentation  (Aug  21-22) 

(6)  Final  Working  Session  (Nov. 13) 

Minutes  for  each  of  these  meetings  are  included  in  Appendix  B,  below. 
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E.  Final  Report,  Including  Recommendations 

The  development  of  the  Final  Report  was  a  cooperative  effort  by 
the  Task  4  Team  members,  with  each  member  contributing  assigned 
sections.  In  addition  to  their  assigned  sections,  each  Task  4  Team 
Member  submitted  one  or  more  2-page  recommendation  items.  Tin-  Kina! 
Working  Session  was  used  to  finalize  these  important  results. 

F.  Literature  Review 

Although  many  activity  and  information  modelers  were  contacted 
during  the  survey,  a  formal  review  of  available  literature  on  the 
applications  of  modeling  efforts  was  deemed  necessary.  Because  of  the 
tremendous  scope  of  modeling  methods  being  used  and  the  belief  that 
IDEF  is  the  most  comprehensive  structured  approach,  the  team  limited 
their  review  to  literature  discussing  the  application  of  the  IDEF 
methods.  The  information  obtained  was  integrated  with  survey  data  and 
meeting  notes,  and  supports  the  recommendations  presented  in  Section 
C .  1 . 


Applicable  IDEF  articles  and  technical  report  references  were 
found  through  an  exhaustive  literature  database  search.  Their 
abstracts  were  then  reviewed  to  identify  pertinent  materials. 

Through  interlibrary  loans  and  the  Team’s  library  archives,  the 
identified  articles  were  found  and  subsequently  reviewed. 

The  review  and  assessment  of  the  IDEF  articles  generated  a  list 
of  both  negative  and  positive  issues  as  described  by  the  authors. 
This  list  has  been  categorized  below.  The  issues  listed  provide  a 
high-level  summarization  of  the  major  positive  and  negative  points 
found  in  the  literature  search. 


Positive : 

Negative : 

(1) 

Supports  many  disciplines 

(1) 

Unfamiliar,  applied 
narrowly  to  Mantech 

(2) 

Represents  real  U3er  needs 

(2) 

Not  simulatable,  lacks 
other  language  extensions 

(3) 

Provides  an  integrated  picture 

(3) 

Costly  and  time-consuming 

(4) 

Excludes  political  issues 

(4) 

Lacks  guidlines 

(5) 

Able  to  conceptualize  the  future 

(6) 

Provides  a  stable  info  structure 

(7) 

Catches  redundancies,  missing, 
organization  processes 

(8) 

Results  are  structured 

With 

the  exception  of  the  unfamiliarity 

of  the  method  and  its 

percieved 

(but  not  warranted)  restriction 

to 

the  Mantech  application 

arena,  each  of  the  four  major  objections  from  the  literature  is 
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addressed  by  at  least  one  of  the  Recommendations  in  the  Strategic 
Plan.  The  ability  to  use  IDEF  models  as  a  basis  for  simulation,  and 
the  addition  of  other  missing  langauge  constructs,  are  included  in 
Recommendations  2  and  7.  The  cost  and  time-consuming  nature  of  the 
modeling  is  greatly  alleviated  by  several  of  the  recommenations : 
Recommendation  1  (a  lifecycle  methodology) ,  Recommendation  3 
(templates  to  support  standardized  IDEF  application),  Recommendation 
5  (reusable  models  and  configuration  control).  Recommendation  9 
(application  Rule  Sets),  and  Recommendation  11  (standards  and 
guidelines) ,  each  contributes  to  reducing  the  cost  and  time  required 
to  develop  models.  The  lack  of  proper  guidelines  for  applying  IDEF 
is  addressed  by  Recommendation  11. 

G.  Summary 

The  Task  4  Team  began  with  the  goal  of  assessing  IDEF’s  activity 
and  information  modeling  methods  in  light  of  needed  support  for 
enterprise  framework  applications.  The  CIM-OSA  Framework  and 
Lifecycle  became  the  primary  framework  in  the  assessment,  and  an  in- 
depth,  3-day  technical  session  was  held  to  explore  specific  CIM-OSA 
support  issues  with  CIM-OSA  experts.  The  IDEF  User  Group  and  a  list 
of  key  organizations  and  individuals  were  also  surveyed,  as 
additional  important  sources  of  needs.  Presentations  of  draft 
findings  and  recommendations  were  made  at  various  times  to  the  IDEF 
User  Group  Steering  Committee  as  well  as  the  User  Group  attendees  at 
meetings . 

The  assessment  resulted  in  a  list  of  eleven  recommendations  for 
IDEF  enhancements,  with  each  member  of  the  Task  4  team  contributing 
to  the  list.  These  recommendations  were  then  prioritized  and 
incorporated  into  a  Strategic  Plan,  including  a  roadmap  and  specific 
recommendations  regarding:  investment  strategy,  what  should  be  done, 
how  it  should  be  pursued,  and  the  form  of  the  outputs  for  each  effort 
in  the  roadmap.  Section  4  of  this  report  presents  the  Strategic 
Plan . 


APPENDIX  A 

SURVEY  OF  THE  INDUSTRY 


A.l  The  Survey  Procedure 

Once  the  scope  of  the  survey  was  determined,  a  literature  search 
was  started  for  all  recent  articles  on  IDEE.  While  this  was  being 
performed,  the  Team  developed  a  list  of  experts  to  whom  a 
questionnaire  would  be  sent  to  solicit  information  for  the 
assessment.  Once  the  list  of  experts  and  a  generic  list  of  questions 
was  developed,  reviewed,  and  approved,  the  survey  was  conducted. 

To  initiate  the  survey,  each  team  member  personally  contacted  a 
subset  of  the  Source  List,  and  discussed  the  questions.  Once  the 
telephone  contact  had  been  made,  a  cover  letter  and  the  formal  list 
of  questions  was  mailed  out.  When  time  became  short,  the  cover 
letter  and  the  set  of  questions  was  mailed  without  the  telephone 
contact  step. 

The  survey  results  identified  and  assisted  in  the  definition  of 
needs,  requirements,  and  recommendations  of  activity  and  inforn,  i  on 
modeling  methods.  Information  was  received  on  potential  enhance  wni.s, 
lessons  learned,  and  target  opportunities  for  the  use  of  activity  and 
information  modeling  methods. 

In  the  remainder  of  this  section,  the  cover  letter  and 
questionnaire  are  reproduced,  to  document  the  survey  material  as 
distributed  to  the  Source  List. 

A.  2  The  Survey  Questionnaire 

[Address  of  person  to  be  visited] 

Dear  : 


Thank  you  for  agreeing  to  participate  in  our  assessment  of 
activity  and  information  modeling  methods.  This  letter  is  to  provide 
additional  background  information  on  the  project,  and  to  provide  a 
list  of  questions  regarding  analysis  methods  and  frameworks  of 
methods . 

BACKGROUND 

There  is  an  Air-Force-sponsored  study  under  way  to  identify  and 
prioritize  enhancements  to  the  IDEF  Methods  (both  activity  and 
information  modeling) .  The  project  is  a  5-month  team  effort  by 
SofTech,  CDC,  and  BDM  International. 

This  team  is  presently  assembling  information  on  potential 
enhancements.  Once  all  sources  of  recommendations  have  been 
surveyed,  the  team  will  assess  the  results,  prioritize  the 
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recommendations,  and  present  this  material  to  both  the  IDEF  User 
Group  and  the  Air  Force  sponsors  at  WPAFB/WRDC/MTI . 

The  objectives  are  to 

(1)  assess  existing  "Framework"  initiatives  such  as 
CIM/OSA,  and  to  identify  requirements  for 
improved  IDEF  support  for  these  efforts 

(2)  develop  a  "strategic  focus"  and  a  strategy  for 
accomplishing  the  needed  improvements 

(3)  prioritize  targets  of  opportunity 

(4)  benefit  from  "lessons  learned" 

(5)  prepare  the  recommendations  in  the  form  of  both 
a  technical  and  a  business  strategy 

The  final  result  of  the  effort  will  be  a  Strategic  Plan.  This 
plan  will  include  a  "Vision  Statement"  which  identifies  perceived 
industry  directions  and  general  needs,  lists  specific  needs,  and 
presents  specific  recommendations,  including  a  rationale  and 
anticipated  benefits  resulting  from  each  recommendation. 

Our  team  is  interested  in  your  ideas  and  insights  regarding 
Framework-driven  IDEF  requirements  as  well  as  any  "lessons  learned" 
from  your  experience  using  IDEF  or  other  similar  Enterprise  Analysis 
methods.  Any  documents,  presentations,  or  other  hard-copy 
information  you  could  provide  that  would  help  ensure  correct 
understanding  would  also  be  appreciated.  Also,  if  you  have  names  of 
other  points  of  contact  for  further  insight,  please  provide  a  name 
and  means  of  contacting  them. 

LIST  OF  QUESTIONS 

The  attached  list  of  questions  is  for  your  consideration.  We  do 
not  necessarily  expect  you  to  provide  an  answer  to  each  of  the 
questions;  they  are  intended  to  cover  the  broad  scope  of  our 
assessment,  and  each  information  source  will  find  a  subset  of  the 
questions  of  particular  relevance  to  his  experience  with  IDEF. 

The  list  attempts  to  capture  key  issues  of  concern  to  the 
industry,  but  we  anticipate  that  you  may  have  specific  issues  to 
raise  that  may  not  be  on  the  list.  Please  feel  free  to  do  so.  Also, 
if  other  issues  come  up  later,  we  would  appreciate  your  writing  or 
phoning  in  these  further  thoughts.  Please  send  or  FAX  your  response 
to: 


[Point  of  Contact] 
SofTech,  Inc. 

460  Totten  Pond  Road 
Waltham,  MA  02154-1960 
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FAX:  (617)  890-6055 


We  wish  to  make  this  effort  as  complete  and  responsive  to  real 
needs  as  possible,  and  we  appreciate  your  assistance  in  this  effort . 
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GENERIC  QUESTIONS  TO  ASK  INFO  SOURCES 
FRAMEWORK  QUESTIONS: 

(a)  How  would  you  define  the  Purpose  of  your  Framework? 

(b)  Does  your  Framework  effort  include  the  specification  of  a 
specific  methods  Architecture,  or  are  multiple  methods 
accommodated? 

(c)  Describe  how  you  plan  to  use  the  Framework  once  it  is 
complete  and  accepted.  Can  you  give  a  scenario  of  an 
Enterprise  improvement  project  which  uses  the  methods 
referenced  by  your  Framework? 

(d)  Does  your  Framework  have  a  formal  definition  (meta 
language) ? 

(e)  How  are  the  individual  cells  in  your  Framework  defined? 
How  are  methods  analyzed  and  included  in  your  Framework? 
Do  you  have  a  "uniqueness  rule"  regarding  information 
fitting  into  a  Framework  cell? 

(f)  How  do  you  define  inter-cell  integration  of  information 
derived  via  application  of  methods? 

(g)  Who  is  responsible  for  pursuing  the  completion  of  your 
Framework,  and  how  is  this  effort  done?  What  are  plans 
for  future  modification  and  maintenance  of  your 
Framework? 

(h)  How  do  you  plan  to  publicize  and  gain  acceptance  for  your 
Framework? 

(i)  What  are  the  restrictions  on  use  of  your  Framework 
material? 

(j)  What  is  the  scope  of  your  Framework?  How  does  it  apply 
to  the  analysis  of  all  aspects  of  an  "Enterprise"? 

(k)  Do  you  wish  to  coordinate  activities  with  the  IDEF 
Framework  effort?  How? 

(l)  May  we  have  copies  of  the  latest  Framework  document?  May 
the  IDEF  User  Group  be  placed  on  your  mailing  list  for 
future  document  distribution? 

(la)  What  is  the  lifecycle  approach/structure  that  drives  your 
info  and  activity  modeling  procedure? 

(lb)  How  would  you  define  an  "Enterprise"? 
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METHODS  QUESTIONS: 


(m)  Types  of  models  and  methods  used?  Activity  models? 
Information  models? 

(n)  What  have  you  found  to  work  well?  What  "voids"  (methods 
applicability  related  to  Framework  requirements)  have  you 
found? 

(o)  Given  the  opportunity  to  extend  methods,  what  extensions 
would  you  make  and  what  priority  would  you  assign? 

(p)  What  training  do  you  use  for  modelers?  What  training 
requirements  do  you  follow?  Do  you  "screen"  candidate 
modelers?  If  so,  how? 

(q)  What  "Structured  Application"  (lifecycle)  procedure  do  you 
use  to  orient  use  of  methods? 

(r)  Where  do  you  see  your  future  methods  requirements  going? 
Where  are  currently  used  methods  going?  What  evolution  do 
you  foresee? 

(s)  Can  you  reference  each  method  used  to  a  definition  or 
textbook?  A  person?  Could  you  send  any  definition 
material  of  this  nature  to  us? 

(t)  What  types  of  hardware  and  software  tools  do  you  use  to 
support  use  of  these  methods? 

(u)  Are  verification  and  validation  checks  of  models  performed? 
What  checks?  How  are  they  made? 

(v)  How  do  you  "package"  your  models?  Can  you  give  us  an 
example? 

(w)  What  standards  (e.g.  PDES)  have  you  considered  and/or  used? 

(x)  Which  groups  and  committees  do  you  participate  in?  To  what 
extent  do  you  participate  (e.g.  conference  attendance, 
participation  in  Working  Groups,  etc.) 

(y)  What  previous  methods  and/or  Frameworks  have  you  considered 
in  your  developments? 

(z)  Do  you  have  corporate  standards  for  Enterprise  Analysis? 

Use  of  IDEF?  What  specific  projects  have  these  standards 
been  applied  to? 

(aa)  Do  you  use  a  Configuration  Management  procedure  for 
Modeling  methods?  How  is  Integration  handled? 

Maintenance? 


(ab)  What  paradigms  do  you  use  to  achieve  an  integrated 
environment?  What  implementation  technology  are  you  using 
(e.g.  Flat  files.  Object  Oriented,  PLC,  etc.)? 

(ac)  What  requirements  does  the  implementation  technology  impose 
on  your  modeling  method? 

(ad)  What  kind  of  cost/benefits  analysis  have  you  found 
applicable  to  your  modeling  method? 

(ae)  Do  you  distinguish  between  ASIS  and  TOBE  models?  What  are 
characteristics  for  each? 

(af)  Do  you  model  the  transition  process  from  the  ASIS  to  the 
TOBE?  What  method  is  used? 
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A.  3  Source  List 

(24) 

Automotive  (GM,  Ford) 

PRIMARY 

(1) 

SEMATECH 

(25) 

NOSC/IFHAMM 

(2) 

CIM/OSA 

(26) 

IMIS 

(3) 

EIF  Related  Contacts 

(27) 

NIST 

:  EIFWG  , 

EIF/NAD,  and  EIF/ IBM 

(28) 

DEC 

(4) 

NAD 

(29) 

DoD  TAT  Report  on  Japan 

OTHER 

(30) 

Teradata,  San  Francisco 

(5) 

PDES 

(31) 

Northeastern  U 

(6) 

CALS 

(32) 

Boeing,  Seattle 

(7) 

TAM 

(33) 

MTC,  Dayton 

(8) 

Meta  Model: 

(34) 

USN,  NUSC,  Newport 

(9)  Contact  #1 

(35) 

Peterson  Builders,  WI 

(10)  Contact  #2 

(36) 

IBM,  Rochester,  MN 

(11)  IPI 

(37) 

DACOM,  Irving,  TX 

(12) 

Mantech  Office 

(38) 

General  Dynamics,  Fort 

(13) 

Boeing 

Worth 

(14) 

GUIDE/ IBM 

(39) 

CA 

DACOM,  Manhattan  Beach, 

(15) 

Tool  Vendors 

(40) 

McDonnell  Douglas,  Long 

(16) 

I  CAPS 

Beach 

(17) 

IMIP/Hanscom 

(41) 

Tabset,  Berkeley 

IMIP/ASD 

(18) 

SEI 

(19) 

RAMP 

(20) 

IDEF  User  Group 

(21) 

DAPRO/1291 

(22) 

Financial  Orgs 

(23) 

CDC 
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A. 4  Response  to  Questionnaires 

All  of  the  41  sources  were  contacted  and  provided  with  the 
formal  list  of  Framework  and  Methods  questions  presented  in  Section 
A. 2.  Many  of  the  sources  responded  verbally,  and  their 
recommendations  are  included  in  Strategic  Plan  Section  4  B.2. 

There  were  20  written  responses  received.  Of  these  20 
responses,  several  contained  more  than  one  person's  response  from  the 
surveyed  organization.  The  types  of  organizations  responding  to  the 
questionnaire  are  categorized  according  to  Table  A-l,  and  the 
responses  are  summarized  in  Figure  A-l: 


Table  A-l.  Response  Categories 


category  Code  Humber  q£  Responses 


Industry 

i 

8 

Academia 

A 

3 

Technical 

Society  T 

3 

Military 

M 

2 

Consultant  C 

4 

Type  of 

Need  Identified 

Related 

Oraanization 

Recommendation 

1  (Industry) 

Enterprise  Scope 

8 

Add'l  IDEFIx  Syntax 

6,7 

IDEFO/lx  Integration 

4 

Object  Orientation 

8 

Full  lifecycle  coverage 

1 

IDEFIx/EXPRESS  integ 

10 

Guidlines  &  Examples 

11 

Executable  Model 

2,5 

A  (Academia) 

IDEFO/lx  Integration 

4 

Add'l  IDEFIx  Syntax 

7 

Object  Orientation 

8 

T  (Tech  Soc.) 

Add'l  IDEFIx  Syntax 

7 

Guidelines  &  Examples 

11 

Training/Use  Control 

9 

IDEFO/lx  Integration 

4 

M  (Military) 

Executable  Model 

2,5 

Validation  Checks 

7 

Dynamics  (IDEF2) 

2 

Enterprise  Scope 

8 

C  (Consul'ts) 

Add’l  IDEFO  Syntax 

7 

Add'l  IDEFIx  Syntax 

7 

Executable  Model 

2,5 

Enterprise  Scope 

8 

Model  Usage  Tools 

5  ! 

Figure  A-l  Summary  of  Identified  Needs  from  Response 
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APPENDIX  B 
MEETING  MINUTES 


B.l  Kickoff  Organizational  Meeting 

The  initial  meeting  of  the  Task  4  Team  (the  "Kickoff  Meeting") 
took  place  on  Wednesday,  May  16.  The  purpose  of  the  meeting  was  to: 
(1)  Discuss  the  background  literature  thus  far  collected,  (2)  Focus 
on  areas  for  the  team  to  concentrate  effort,  (3)  Plan  on-site  visits 
and  related  activities  for  the  rest  of  the  project,  and  (4)  Determine 
strategy  to  meet  with  AMICE/C IM-OSA. 

The  Air  Force  began  by  establishing  the  scope  of  the  Task  4 
effort  to  be  IDEFO,  IDEF1,  and  IDEFlx.  Assessment  of  IDEF3  and  4  is 
beyond  the  project  scope. 

During  the  discussion,  it  was  agreed  that  the  results  of  the 
assessment  were  to  be  presented  in  the  form  of  requirements. 
Requirements  may  influence  framework  development  and  stimulate 
extensions  to  the  IDEF  suite  of  methods.  The  legacy  of  existing  IDEF 
models  and  the  lessons  learned  from  user  modeling  experience  must  be 
taken  into  account.  The  report  should  include  recommended  means  of 
accomplishing  change,  not  just  what  to  change. 

It  was  noted  that  the  Task  4  Assessment  effort  must  have  a 
clearly  stated  "mission" .  This  mission  must  clearly  show  how  the 
effort  fits  into  the  mission  of  the  Mantech  office. 

The  list  of  generic  questions  was  discussed  at  length.  It  was 
decided  that  the  questions  should  cover  two  major  areas:  Frameworks 
and  Methods.  It  was  decided  that  the  draft  list  of  questions  would 
be  distributed  as  a  Kit  to  the  team  members  after  the  meeting  for 
further  additions  and  changes. 

A  special-interest  meeting  was  planned  for  Wednesday  evening  of 
the  IDEF  User  Group  meeting  to  solicit  input  from  the  members. 

Written  recommendations  will  be  encouraged.  Also,  a  special 
presentation  should  be  made  to  the  IDEF  User  Group  Steering 
Committee . 

The  criteria  for  evaluating  methods  was  discussed.  It  was 
decided  that  the  criteria  should  include:  Investment  required, 
return  on  investment,  preservation  of  the  legacy  of  existing  models, 
and  long-term  Air  Force  needs  (how  it  will  help  our  defense,  economic 
health,  etc . ) . 

The  Task  4  Assessment  project's  dileverables  were  broken  down 
into  three  areas:  the  Objectives,  the  Strategic  Plan,  and  the 
Recommendations.  A  draft  outline  of  each  of  these  three  areas  was 
generated  on  an  overhead  transparency,  and  a  copy  distributed  before 
the  close  of  the  meeting,  for  the  members  to  review  and  revise.  The 
following  is  a  copy  of  the  three  first  draft  slides: 
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DRAFT  SLIDE  NO.  1 


INITIAL  DRAFT  OBJECTIVES 

(1)  Perform  assessment  of  methods  requirements  needed  to  suport 
framework  activities 

(2)  Identify  and  prioritize  targets  of  opportunity  and  voids 

(3)  Align  task  requirements  with  the  long-term  MTI  goals  and 
objectives 

(4)  Develop  recommendations  and  rationale  to  address  potentially 
high 

payoff  requirements 

(5)  Develop  a  sound  and  focused  coordination  strategy  for  MTI 

_ interations  (both  inter-agency  and  government-industry) 2 _ 

DRAFT  SLIDE  NO.  2 


STRATEGIC  PLAN 

BACKGROUND 

Summary  of  extent  of  task  effort 

Brief  assessment  of  each  major  framework  initiative  under  way 
Mantech  Mission  context  (related  to  this  task) 

VISION  STATEMENT 

Where  is  the  Industry  headed? 

(1)  Frameworks 

(2)  Methods 

(3)  Implementation  Technologies  (tools  and  architectures) 

RATIONALE 

Why  the  effort  is  important  for  the  Air  Force 

NEEDS 

Needs  forced  by  the  Frameworks 
Other  needs 


2This  Objective  was  later  removed,  as  being  too  ambitious  for  the  project’s  resources. 
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DRAFT  SLIDE  NO.  3 


RECOMMENDATIONS 

Prioritized 

Each  recommendation: 

(1)  Tied  to  one  or  more  Needs 

(2)  Tied  to  specific  benefits  to  the  Air  Force 
A  single,  overall  Investment  Strategy  recommendation 
Recommendations  broken  into  TECHNICAL,  BUSINESS,  AND  TECH  TRANSFER: 

Technical : 

WHAT  should  be  done 
HOW:  Technical  Strategy 
Business : 

WHAT  Mantech  should  be  doing 
HOW:  Investment  strategy 
Technology  Transfer: 

WHAT  Recommendations  that  can  be  carried  out  by  other 
organizations 

HOW:  Memoranda  of  Agreement  or  Joint  Organizational 
_ Agreements _ 

B.2  Rochester,  Minnesota  CIM-OSA  Meeting 

After  the  CIM-OSA  meeting  in  Rochester,  it  was  decided  to 
develop  and  distribute  a  copy  of  an  Executive  Summary  to  key 
individuals.  The  Air  Force  wrote  a  cover  letter  to  go  along  with  the 
Executive  Summary,  and  originals  of  this  letter  were  mailed  along 
with  each  copy  of  the  document .  The  Air  Force  cover  letter  and  the 
2-page  Executive  Summary  are  included  below. 
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DEPARTMENT  OF  THE  AIR  FORCE 

WRIGHT  RESEARCH  AND  DEVELOPMENT  CENTER  (APSC) 
WRIGMT-P ATTERSON  AIR  FORCE  BASE.  OHIO  4S433-A533 


Arm  ~  WRDC/MTIA  (2d  Lt  T.  Guss  513-255-7371)  2  Aug  1990 

*U“CT:  Manufacturing  Technology  Special  Studies  Task  4 

T<*  See  Distribution  List 

1.  The  objective  of  Task  4  is  to  assess  the  requirements  on  modeling  methodologies, 
and  on  tools  to  implement  those  methodologies,  which  result  from  the  emergence  of 
overarching  national  and  international  frameworks  for  information  system 
integration. 

2.  As  part  of  meeting  this  objective,  the  Air  Force  and  the  Task  4  contractor  team 
consisting  of  SofTech,  CDC,  and  BDM.  are  assessing  the  applicability  of  the  IDEF 
methods  to  the  Computer  Integrated  Manufacturing  -  Open  Systems  Architecture 
(CIM-OSA)  effort.  A  recent  meeting  on  this  topic  was  held  at  the  IBM  facility  in 
Rochester  Minnesota.  An  executive  summary  describing  the  results  of  that  meeting 
is  enclosed  for  your  information. 

3.  The  Air  Force  Manufacturing  Technology  Program  would  like  to  thank  you  for 
your  interest  in  this  effort,  and  will  continue  to  provide  you  with  additional 
information  on  future  Task  4  findings. 


TODD  K.  GUSS.  2d  Lt,  USAF  2  Atch 

Air  Force  Task  4  Program  Manager  1.  Distribution  List 

2.  Executive  Summary 
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EXECUTIVE  SUMMARY 


A.  INTRODUCTION 
A .  1  Purpose  of  the  Meeting 

On  20-22  June  1990,  IBM’s  CIM-OSA  representatives  presented  the 
CIM-OSA  concepts  to  the  Mantech  Task  4  team.  The  purpose  of  the 
presentation  was  to  gain  first-hand  understanding  of  CIM-OSA  and  to 
understand  the  related  requirements  for  Activity  and  Information 
modeling,  especially  relating  to  IDEF. 

A.  2  Findings 

The  information  provided  during  the  meeting  was  highly 
beneficial  toward  accomplishing  the  purpose.  Findings  include: 

(1)  Present  IDEF  methods  satisfy  a  significant 
number  of  CIM-OSA  Life  Cycle  needs. 

(2)  Several  additional  CIM-OSA  needs  can  be  met  if 
specific  enhancements  are  made  to  IDEF. 

(3)  Alignment  with  the  CIM-OSA  Framework  is  needed 
to  make  IDEF  the  "method  of  choice"  by  CIM-OSA 
users . 

(4)  A  significant  number  of  needed  enhancements  can 
be  achieved  by  procedural  definitions,  and  by 
integrating  the  existing  ICAM  System  Development 
Methodology  (SDM)  with  IDEF. 

The  Rochester  meeting  also  pointed  out  the  need  for  technical 
discussions  directly  with  CIM-OSA  Framework  Project  experts.  These 
discussions  are  needed  to  clarify  detailed  technical  issues,  to 
verify  the  Task  4  Team's  preliminary  findings,  and  to  elaborate 
specific  areas  of  IDEF  support  for  CIM-OSA. 

B.  TOPICS  DISCUSSED 

Key  technical  topics  discussed  at  the  meeting  include:  1)  CIM- 
OSA  Framework  Project  update  based  upon  IBM's  understanding,  2) 
mapping  of  CIM-OSA  modeling  requirements  with  IDEF  Activity  and 
Information  Modeling  capabilities,  3)  IBM's  experience  using  IDEF 
for  internal  modernization  projects  (independent  of  CIM-OSA 
considerations),  and  4)  identification  of  IDEF  shortfalls  and 
enhancement  needs  based  upon  CIM-OSA  Framework  application.  Each  of 
these  topics  is  expanded  upon  briefly,  below. 


B . 1  CIM-OSA  Framework  Update 

The  AMICE  Project  of  CIM-OSA  is  attempting  to  establish  a  CIM 
Open  System  Architecture  that  will  enable  enterprises  to  perform 
business  improvements  in  a  real-time  adaptive  mode.  The  scope  of  the 
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architecture  covers  all  types  of  applications  and  complies  with 
evolving  technologies . 

Discussions  in  Rochester  addressed:  architectural  principles, 
structuring  concepts,  flexibility,  basic  architectural  elements, 
functional  viewpoints,  informational  viewpoints,  and  organizational 
issues.  A  PC-based  "storyboard"  presentation  was  used  to  introduce 
CIM-OSA  concepts,  and  detailed  discussions  were  held  on  key  technical 
topics  (Framework  "cube"  elements,  key  CIM-OSA  terms,  definition  and 
relationships  between  CIM-OSA  "constructs",  etc.). 


B.2  CIM-OSA/ IDEF  Mapping 

The  IDEF  method  was  mapped  to  the  requirements,  design,  and 
implementation  phases  of  the  CIM-OSA  life  cycle  steps.  The 
assessment  determined  that  IDEF  partially  or  wholly  supports  more 
than  50%  of  the  steps. 

CIM-OSA  Phase  CIM-OSA  Step  Supported  Not  Supported 

_ _ bv  idef _ by  Idef _ 

Requirements  20  15  4  Behavior 

1  Integration 

Design  95  4  Resources 

Implementation  9  N/A 


The  results  of  the  mapping  exercise  show  a  high  degree  of  IDEF 
support  for  the  requirements  and  design  phases.  Furthermore,  a 
limited  number  of  enhancements  will  significantly  improve  the 
opportunity  to  apply  the  methodology  on  a  much  broader  basis. 

B.3  IBM's  IDEF  Experience 

IBM  was  asked  to  present  all  positive  and  negative  IDEF  usage 
experiences.  The  positive  points  outnumbered  the  few  negative 
points.  In  general,  IBM  has  found  IDEF  very  helpful  and  has  adopted 
it  as  the  corporate  "method  of  choice"  for  internal  CIM  Projects, 
including  "IBM  Worldwide". 

Specific  points  mentioned  include:  IDEF  provides  rigor  to 
analysis  efforts,  which  had  been  lacking  prior  to  IDEF  use;  IBM  has 
developed  courses  which  are  now  available  for  in-house  IDEF  training; 
present  IDEF  User  Manuals  are  insufficient  for  a  complete 
understanding  of  the  full  role  and  application  of  IDEF;  IDEF  should 
be  driven  by  a  "repository  of  IDEF  models"  to  reduce  startup  efforts; 
rho  inclusion  of  an  experienced  IDEF  modeler  on  the  staff  of  each  new 
1 1  >  l-‘.  I-‘  project  is  cri!  ic.il;  ni.in.iMcnuMil.  support.  >>l  in  I  OKI-'  ptojfd  i 
critical;  the  computer-supported  "living  model"  concept  is  a  helpiul 
aspect  of  CIM-OSA  that  should  be  carried  over  to  IDEF. 


B.4  IDEF  Shortfalls  and  Enhancements 
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Several  IDEF  shortfalls  were  identified  based  upon  IBM 
experience  (both  from  internal  IDEF  use,  and  as  related  to  CIM-OSA) . 
The  top  five  enhancements  aimed  at  correcting  current  IDEF  shortfalls 
were : 


(1)  Integration  of  the  ICAM  System  Development 
Methodology  (SDM)  with  the  IDEFO ,  IDEF1 ,  and 
IDEFlx  methods  and  training  manuals. 

(2)  Enhancement  of  the  IDEF  models  to  be  executable 
at  the  Design  level. 

(3)  Construction  of  an  IDEFlx  information  model, 
using  the  CIM-OSA  templates  for  model  focus. 

(4)  Integration  of  IDEFO  and  IDEF1  by  cross¬ 
correlation  of  related  elements. 

(5)  Validation  and  formalization  of  the  syntax, 
semantics,  and  pragmatics  of  the  identified 
enhancements . 

C .  SUMMARY 

There  is  a  growing  need  for  methods  that  support  analysis, 
design,  and  integration  efforts.  IDEF  has  already  been  shown  to  meet 
these  needs  within  the  DoD  industrial  community.  An  opportunity  now 
exists  to  position  IDEF  to  meet  equivalent  needs  in  the  broader 
industrial  community.  Improvements  to  the  existing  methodology  can 
be  leveraged  for  increased  benefits  to  the  DoD  and  to  industrial  IDEF 
users  to  better  meet  the  challenges  of  Computer  Integrated 
Manufacturing  as  envisioned  for  the  decade  ahead.  Furthermore,  the 
significant  investments  in  IDEF  development  and  application  can  serve 
as  the  stepping-stone  which  build  upon  the  Air  Force  investment  and 
make  use  of  the  valuable  legacy  of  IDEF  models  and  IDEF 
communications  capabilities  already  established  in  industry. 

The  CIM-OSA  meeting  in  Rochester  was  a  significant  step  in 
accomplishing  this  vision  by  providing  the  opportunity  to  probe  into 
the  specific  IDEF  enhancements  that  are  needed  to  meet  this 
challenge.  The  results  of  this  meeting  will  serve  very  well  as  a 
basis  for  further  detailing  technical  points  with  representatives  of 
the  AMICE  Project,  and  in  cementing  CIM-OSA  cooperation  with  the  IDEF 
community . 
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B.3  July  Working  Session 


The  meeting  convened  with  the  following  purpose  and  objectives: 
to  review  and  discuss  the  findings  to  date,  to  plan  the  remainder  of 
the  work  to  be  accomplished,  to  lay  out  the  structure  of  the  final 
report,  and  to  begin  work  on  elements  of  the  final  report. 

I .  REVIEW  OF  STATUS 

A.  Solicitation  of  IDEF  Enhancement  Needs 

At  a  previous  meeting,  assignments  had  been  made  to  each  of  the 
three  contractors  to  contact  a  list  of  information  sources  regarding 
IDEF  enhancements.  A  solicitation  letter  had  been  developed  and 
distributed  to  the  contractors,  for  use  in  this  solicitation. 

A  review  of  the  status  of  this  effort  revealed  that  the  effort 
is  behind  schedule.  The  following  table  summarizes  the  status  as  of 
the  July  23  meeting: 


Info 

Number 

Awaiting 

Responses 

41 

18 

12 

6 

All  contractors  agreed  to  put  an  extra  effort  into  completing 
the  information-gathering  effort  as  soon  as  possible.  To  speed  up 
the  process,  it  was  agreed  that  those  information  sources  who  had 
submitted  business  cards  in  response  to  the  announcement  during  the 
May  IDEF  User  Group  meeting,  need  not  be  contacted  by  telephone 
individually  before  being  sent  the  solicitation  letter.  This  will 
permit  8  of  the  "uncontacted"  sources  to  be  sent  letters  immediately; 
this  should  speed  up  the  process  significantly. 

It  was  agreed  that  the  goal  of  the  solicitation  is  to  contact 
everyone  on  the  list.  The  Task  4  group  cannot  guarantee  receiving 
responses  from  everyone,  but  everyone  must  have  been  contacted  before 
the  solicitation  task  can  be  considered  complete. 

However,  even  with  the  new  procedure  in  place,  it  was  clear  that 
the  schedule  is  not  feasible,  and  that  a  no-cost  extension  of  the 
Period  of  Performance  is  in  order.  This  was  agreed  to,  and  the 
process  of  obtaining  an  extension  will  be  pursued  as  an  action  item 
for  SofTech. 

B.  Completion  of  the  Executive  Summary  of  the  Rochester  CIM- 
OSA  Meeting 

It  was  agreed  that  the  latest  draft  of  the  Executive  Summary  was 
acceptable,  except  for  Section  B.2  (CIM-OSA/IDEF  Mapping).  This 
needs  to  state  the  findings  in  a  clearer  way  for  the  level  of 
readership  anticipated.  The  group  worked  on  re-wording  this  section 
during  the  session  set  aside  for  "Work  on  Individual  Report 


B-8 


Sections".  The  resulting  new  section  was  entered  into  the  master 
file,  re-printed,  and  distributed  to  the  attendees  at  the  start  of 
the  July  24  session. 

The  reasons  for  IDEF  not  supporting  individual  CIM-OSA  life 
cycle  steps  broke  down  into  three  categories:  Behavioral  Aspect:;  (1 
steps).  Integration  (1  step),  and  Resources  (4  steps).  This 
succinctly  summarizes  the  voids  in  the  IDEF  methods  from  a  CIM-OSA 
perspective.  The  Executive  Summary  will  be  distributed  to  a  list  of 
key  government  and  industry  representatives. 
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II.  DISCUSSION  OF  THE  FINAL  REPORT  LAYOUT,  CONTENT, 
ASSIGNMENTS 

The  Final  Report  outline  was  discussed  and  modified.  It  was 
agreed  that  the  first  drafts  of  all  sections  would  be  submitted  by 
August  10,  and  the  summarized  complete  draft  submitted  by  August  15. 

The  following  is  the  revised  outline,  showing  the  estimated  size 
of  each  section  and  the  person  responsible  for  writing  the  first 
draft  of  the  section. 
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III.  WORK  ON  INDIVIDUAL  REPORT  SECTIONS 

With  the  work  on  the  Executive  Summary,  the  time  allotted  to 
this  effort  was  reduced.  However,  before  the  end  of  the  session,  the 
Final  Report  Section  2,  "Industry  Directions",  was  partially  written 
and  distributed  to  the  team  members. 

IV.  RECOMMENDATIONS: 

The  status  of  the  recommendations  identified  as  a  result  of  the 
Task  4  assessment  to  date  was  summarized  in  the  following  list  of  8 
recommendations  (subsequently  increased  to  11) : 

1.  Integrate  ICAM  and  SDM  into  IDEF  Suite 

2.  Enrich  IDEF  models  sufficiently  to  be  executable  at 
design  level 

3.  Construct  an  IDEFlx  data  model  of  CIM-OSA  templates 

4 .  Integrate  IDEFO  and  IDEFlx 

5.  Develop  more  design-level  packaging/structuring 
constructs 

(a)  Data  Flow  concepts  ->  Activity  Models 

(b)  External  and  Internal  data  structuring  concepts 
(screens /reports) 

6.  Concepts  and  Tools  to  support  re-use  and  Configuration 
Management  of  IDEF  Models 

•  Re-use 

•  CM 

•  Training 

•  Clarification 

•  Simulation  (Timing/Performance  analysis) 

•  Cost  Benefit  analysis 

•  Impact  analysis 

•  Integration  Characteristics 

7.  IDEFO  and  IDEFlx  usability  enhancements  and  extensions 
derived  from  experts  and  users  in  practise 
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8.  Usage  def init ion/Rule  sets  (Examples  and  Training) 

(Enrich  IDEFO  and  IDEFlx  with  constructs  or  rule  sets  to 
permit  modeling  and  specification  of  behavior) 

Note:  includes  two  typesof  rule  sets:  "How  to  Model" 

rule  set  for  developing  models,  and  "IF-Then"  type  rules 
for  developing  CIM. 

V.  PLANS  AND  ACTION  ITEMS 

A.  Plans  for  the  Next  meeting  (August  20) 

The  next  Task  4  Team  Meeting  will  be  held  in  Dayton  on  August 
20,  the  day  prior  to  the  IDEF  User  Group  Steering  Committee  meeting. 
The  purpose  of  the  meeting  will  be  to  assess  project  status  and  to 
review  Task  4  presentation  material.  The  scheduled  submission  of  the 
draft  Final  Report  sections  by  August  10  is  the  key  Action  Item  that 
will  make  this  schedule  feasible. 

B.  Plans  for  User  Group  presentation  in  February 

It  is  anticipated  that  the  Steering  Committee  presentation  will 
provide  the  basis  of  a  presentation  to  be  made  to  the  full  User  Group 
at  their  next  meeting.  By  that  time,  the  Final  Report  should  be 
completed,  and  the  full  User  Group  should  be  informed  regarding  the 
results  of  the  Task  4  effort. 

VI .  HANDOUTS 

At  the  start  of  the  July  24  session,  several  handouts  were 
distributed  to  the  task  4  team: 

•  IDEFO  Model  of  Framework  Tasks 

•  Recommendations  from  the  Solicitation 

•  Draft  Rochester  Trip  Minutes 

•  Revised  Executive  Summary  of  Rochester  Meeting 

•  CIM-OSA  Response  to  the  AF  Letter  of  Intent 

•  Mantech  Objectives  Material 

•  Final  Report  draft  material 

B.4  August  Meeting  and  IDEF  Steering  Committee  Presentation 

On  August  20,  the  Task  4  Team  met  just  prior  to  the  IDEF  User 
Group  Steering  Committee  meeting,  to  prepare  a  presentation  of  the 
draft  recommendations  to  that  group.  The  following  is  the  list  of 
overhead  slides  presented  to  the  Steering  Committee  on  August  21. 
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(1)  Task  4  Objectives 

(2)  Description  of  Work 

(3)  Needs  Solicitation 

(4)  Reports  &  Communities  Surveyed 

(5)  IDEFO  Diagram  of  the  Project  tasks 

(6)  Gannt  Chart  of  the  project  timetable 

(7)  Relation  to  CIM-OSA 

(8)  Purpose  of  the  IDEF-UG  Framework 

(9)  Framework  Cell  relationship  to  methods 

(10)  Benefits  Resulting  from  Framework  Use 

(11)  IDEF  Family  of  Methods 

(12)  Method  Enhancement  DO ' s  and  DON'Ts 

(13)  The  eleven  recommendations 

The  majority  of  the  question  and  answer  session  was  occupied  by 
a  discussion  of  the  eleven  recommendations.  Following  the  meeting, 
the  Task  4  Team  agreed  that  the  presentation  material  would  serve  as 
a  basis  for  future  presentations  of  the  Task  4  findings. 

B.5  Final  Task  4  Team  Meeting 

The  Task  4  Team  met  for  the  last  time  on  November  13  for  the 
purpose  of  making  final  changes  to  the  Final  Report  document.  Lt . 
Guss  was  unable  to  attend. 

The  editing  pass  over  the  draft  final  report  was  provided  by 
BDM,  and  this  material  was  turned  over  to  SofTech  for  processing.  A 
revised,  standardized  format  was  recommended  for  the  Final  Report, 
and  it  was  noted  that  the  Task  4  report  would  now  have  the  same 
format  as  the  Task  5  report . 

Several  issues  were  decided: 

•  An  introduction  to  the  Executive  Summary  was 
developed,  to  set  the  charter  and  scope  of  the 
Task  4  effort  before  describing  the 
accomplishments . 

•  The  Executive  Summary's  new  categorized  list  of 
recommendations  was  discussed.  It  was  decided 
that  this  is  an  acceptable  middle  position 
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between  including  each  recommendation  (too 
lengthy)  and  providing  a  brief  summary  (too 
short) . 

•  CDC  recommended  that  the  Roadmap  Chart  be 
included  full-size  on  a  separate  page,  since  it 
is  very  small  print  and  is  likely  to  become 
unreadable  after  multiple  copying. 

•  The  draft  survey  of  available  COTS  tools  related 
to  the  IDEF  methods  was  submitted.  The  Team 
members  had  several  additions  to  the  draft  list 
of  COTS  tools . 

•  The  new  matrix  "mapping  problems  to  solutions" 

(Figure  4-1)  was  edited  and  expanded. 

A  request  was  made  that,  once  the  changes  have  been  made,  the 
Task  4  Team  wishes  to  have  a  final  draft  to  review  one  more  time, 
before  submitting  the  Final  Report  to  the  Air  Force. 

B.6  IDEF  User  Group  Meeting 

Although  not  strictly  a  Task  4  Team  meeting,  material  from  the 
session  held  at  the  IDEF  User  Group  Meeting  in  May  is  included  here. 

A  synopsis  of  the  meeting  is  included  above,  in  Section  5. A  "IDEF 
User  Group  Meeting". 

There  were  four  overhead  projector  slides  developed  for  and  used 
at  the  special  Task  4  Wednesday  evening  session.  These  slides 
summarize  the  goals,  objectives,  and  strategic  plan  outline.  The 
material  from  the  slides  is  included  here  for  the  record.  Also,  it 
is  anticipated  that  the  material  will  be  useful  when  presenting  Task 
4  to  other  groups  in  the  future. 
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SLIDE  1:  OVERVIEW 


Air  Force  Sponsored  Assessment  to  Identify  and 
Prioritize 

Activity  &  Information  Modeling  Enhancements 
OVERVIEW 

•Team  Effort  -  SofTech,  CDC,  BDM,  DEC 
•Assessment  Information  on  Enhancements 
•Perform  Assessment 

•  Prioritize  Recommendations  &  Strategy 

•  Present  Report  to  IDEF  UG  &  WRDC 

•  Five  Month  Effort 

SLIDE  2:  OBJECTIVES 

OBJECTIVES 

•  Assess  Framework  Initiatives  and  Identify  Requirements 

for  Improved  IDEF  Support  (Activity  &  Info) 

-  SEMATECH 

-  CIM-OSA 

-  Others 

•  Develop  Strategic  Focus  with  Investment  Strategy 

•  Prioritize  Targets  of  Opportunities 

•  Identify  Lessons  Learned 

•  Prepare  Results 

-  Technical 

-  Business 
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SLIDE  3:  STRATEGIC  PLAN  OUTLINE 


DELIVERABLES: 

Strategic  Plan 
Background 
Vision  Statement 

•  Industry  Directions  and  Needs 
Rationale  for  Effort 

Needs 

•  Framework  Driven 
Recommendations 

•  Description 

•  Related  Need(s) 

•  Benefits 

•  Business  Strategy 

Directed  to:  WRDC/MTI 

IDEF-UG 


SLIDE  4:  SOLICITATION  OF  RECOMMENDATIONS 

YOU  CAN  HELP!  -  YOU  CAN  BENEFIT! 

•  Provide  Your  Ideas  and  Insights  Associated  with 
Framework  Driven  IDEF  Requirements  (Activity  &  Info) 

•  Provide  Suggested  Points  of  Contact  for  Further  Insight 

•  Provide  "Lessons  Learned"  Experience 

•  Identify  Documents /In format  ion  You  Can  Send 


THE  COMPILED  RESULTS  WILL  BE  PROVIDED  TO  THE 


IDEF-UG  FOR  UG  PARTICIPANT  ACTIVITIES. 
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APPENDIX  D 

CIM-OSA/ldef  MARRIAGE 


D . 1  IBM 


Document 


(See  next  page) 
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CIM-OSA  Life  Cycle  and  IOEF 


Table  2  (Page  1  of  <).  CIM-OSA  Life  Cycle  and  IDCF  Support 


1DEF  RECORDING 
MECHANISM 


•  Author  recorded  on 
IDEF  cover  sheet. 

•  Responsible  Design 
Authority  not  nec¬ 
essarily  recorded 


Control  arrows  on  dia¬ 
grams 


CIM-OSA  LIFE 

CYCLE  METHOD¬ 
OLOGY 

IDEF  ENFORCED 

Requirements  Phase 

Assign  Responsible 

Design  Authority 

PARTIAL 

List  the  objectives  and 
Constraints 

PARTIAL 

Formalize  the  objectives 
and  constraints 

NO 

Identify  DOMAIN 
Processes  that  address 
the  objectives  and  con¬ 
straints 

YES 

Identify  DOMAIN  for 
the  DOMAIN  Process 
Functions 

YES 

Identify  the  Object 

Gasses 

YES 

Ensure  DOMAIN 

Object  Gasses  are 
refined  to  the 

DOMAIN  Process  level 

YES 

Identify  sources  and 
destinations  of  external 
Object  Gasses  and  their 
external  DOMAINS. 

YES 

Identify  DOMAIN 
RELATIONSHIPS 

PARTIAL 

Define  functional  part 
of  DOMAIN  and 
DOMAIN  PROC¬ 
ESSES  (first  level 
decomposition) 

PARTIAL 

Define  the  Behavioral 

Part  of  the  DOMAIN 

NO 

Decompose  the 

DOMAIN  PROC¬ 
ESSES 

YES 

IDEFo  Activities 


A-0  Diagram 


Inputs,  Outputs  and 
Controls  on  Diagrams 


Inputs,  Outputs  and 
Controls  on  Diagrams 


A- 1  Diagrams 


A-l  Diagram 


Description  of  functions 
and  I/O  provided  in 
text 


IDEFo  Diagrams 


D-2 


Table  1  (Page  2  of  4).  C1M-OSA  Life  Cycle  and  IOEF  Support 


IDEF  RECORDING 
MECHANISM 


Inputs,  Outputs  and 
Controls  on  diagrams 


Description  of  function 
and  I/O  provided  in 
text 


CIM-OSA  LIFE 

CYCLE  METHOD¬ 
OLOGY 

IDEF  ENFORCED 

Identify/refine  object 
classes  for  the  business 
process  level 

YES 

Define  functional  part 
of  the  business  proc- 

PARTIAL 

Define  the  Behavioral 

Part  of  the  DOMAIN 
Processes 

NO 

Decompose  the  busi¬ 
ness  processes  (enter¬ 
prise  activities) 

PARTIAL 

_ 

Identify/Refine  Object 
classes  for  the  enterprise 
activity  level 

YES 

Define  functional  part 
of  the  enterprise  activ¬ 
ities 

PARTIAL 

Define  the  behavioral 
part  of  the  business 
processes 

NO 

Identify  OBJECTS 

YES 

Derive  the  external 
schema 

NO 

Identify  INFORMA¬ 
TION  ELEMENTS 

NO 

*  Activities  cannot  be 
shared  in  IDEF 

•  Can  be  made  pos¬ 
sible  if  SADT 
(System  Analysis 
and  Design  Tech¬ 
nique)  Calls  are 
incorporated  in 
IDEF. 


Inputs,  outputs,  con¬ 
trols  on  diagrams 


Description  of  function 
and  I/O  provided  as 
text 


IDEFo  Flows 


Design  Phase 

Assign  Responsible 

Design  Authority 

PARTIAL 

•  Author  recorded  on 
IDEF  cover  sheet. 

•  Responsible  Design 
Authority  not  nec¬ 
essarily  recorded 
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|  Table  1  (Page  3  of  4).  CIM^OSA  Life  Cycle  and  IDEF  Support 

CJM-OSA  LIFE 

CYCLE  METHOD¬ 
OLOGY 

IDEF  ENFORCED 

IDEF  RECORDING 
MECHANISM 

Identify  alternative 
resources  for  Required 
Capability  listed  with 
each  EA. 

NO 

ICAM  System  Devel¬ 
opment  Methodology 
(SDM)  addresses  but  is 
not  part  of  the  IDEF 
users  manual. 

Define  Alternative  or 
refine  existing  EA's 


Select  from  alternatives 


Define  the  EA  func¬ 
tional  operations  based 
on  the  resource  analysis 


Specify  Resource  and 
Capacity 


Derive  the  conceptual 
schema 


Derive  consistency  con¬ 
straints 


Identify  I/O  volumes 
for  each  functional 
operation 


Implementation  Phase 


•  Choose  products 

•  Define  implemented 
capabilities 

•  Define  locations 

•  Define  dynamics 


Define  fragmentation 
and  distribution  of  data 


Define  Implemented 
Functional  Entities 


Define  communication 
requirements 


PARTIAL 


PARTIAL 


PARTIAL 


IDEFo  Mechanisms 
(not  quantitative) 


•  Activities  cannot  be 
shared  in  IDEF 

•  Can  be  made  pos¬ 
sible  if  SADT 
(System  Analysis 
and  Design  Tech¬ 
nique)  Calls  are 
incorporated  in 
IDEF. 


IDEFo  Mechanisms 
(not  quantitative) 


IDEF  lx  Diagrams/Text 


Cardiality,  Referential 
Integrity,  Entity  Integ¬ 
rity 


ICAM  SDM  addresses 
but  it  is  not  part  of  the 
IDEF  users  manual 


Tab)#  1  (Page  4  of  4).  CIM-OSA  Life  Cycle  and  IDEF  Support 

CIM-OSA  LIFE 

CYCLE  METHOD¬ 
OLOGY 

IDEF  ENFORCED 

IDEF  RECORDING 
MECHANISM 

Define  communication 
resources 

NO 

Describe  how  to  store 
per  data  location  and 
develop  internal  schema 

NO 

Define  storage  resources 

NO 

• 

Select  Products 

NO 
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D .  2  Task  4  Team  Document 


This  paper  is  a  limited  comparison  of  the  IDEF  and  CIM-OSA 
methodologies.  It  identifies  several  of  the  outcomes  from  the 
document  presented  by  IBM  Corporation  entitled,  The  CIM-OSA  and  IDEF 
Marriage,  and  the  discussion  regarding  the  IBM  document  at  meetings 
held  in  Rochester,  Minnesota. 

The  overall  outcome  of  this  comparison  and/or  analysis  of  the 
two  methodologies  agrees  with  that  offered  in  the  IBM  document  as  it 
stated  that  IDEF  can  support  the  CIM-OSA  methodology  with  some  minor 
revisions.  The  CIM-OSA  methodology  does  provide  for  several  areas 
that  the  IDEF  methodology  does  not  provide  for,  but  IDEF  also 
provides  for  areas  not  addressed  in  CIM-OSA.  The  area  (at  a 
methodology  overview  level)  where  IDEF  offers  the  user  an  advantage 
over  CIM-OSA  is  that  of  executive  level  strategic  planning.  The  areas 
that  (at  a  methodology  overview  level)  where  CIM-OSA  offers  the  user 
an  advantage  over  IDEF  include  the  generation  and  use  of  reference 
models,  the  implementation  phase  coverage,  and  the  behavioral  aspects 
built  into  the  models  which  can  be  used  for  day-to-day  control  of 
operations . 

Additional  information  regarding  the  38  CIM-OSA  Life  Cycle 
Steps,  as  outlined  in  the  IBM  document,  is  given  below.  This 
information  supplements  and  expands  upon  the  information  provided  by 
SofTech  in  the  minutes  of  the  Rochester,  Minnesota  meeting. 

STEP  -  DISCUSSION  OF  STEP 

REQUIRMENTS  PHASE 

1.  Assign  Design  Responsibility  -  CIM-OSA  requires  that  the 
author/designer  of  the  model  be  assigned  and  called  out  in 
addition  to  the  owner  of  the  process  being  modeled. 

IDEF  requires  that  the  author  of  each  diagram  be  assigned  but 
does  not  require  the  assignment  of  the  owner  of  the  process  nor 
the  designer  of  the  process.  IDEF  does  allow  for  this  assignment 
but  at  this  time  does  not  require  it. 

To  make  the  two  methodologies  compatible,  IDEF  could  be  augmented 
with  a  template  or  cover  sheet  that  would  set  the  requirements 
for  each  model.  Included  in  this  cover  sheet  would  be  the 
requirement  to  use  the  existing  capability  to  call  out  the  owner 
of  the  process  being  modeled. 

2.  Identify/Formalize  Objectives  and  Constraints  -  This  step  in  the 
CIM-OSA  methodoloqy  requires  additional  clar if icat ion  for  the 
terms  used.  The  assessment  team  was  unfamiliar  with  the 
definitions  of  Objectives  and  Constraints  as  they  relate  to  CIM- 
OSA.  CIM-OSA  does  have  the  capability  for  dynamic  flow 
requirements  which  enable  it  to  be  used  as  a  simulation  tool. 
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IDEF  would  require  additional  information,  forced  through  the 
aforementioned  coversheet/template,  in  order  for  it  have  the 
ability  for  simulation  or  dynamic  flow  characteristics. 

Additional  definition/clarification  of  CIM-OSA  Objectives  and 
Constraints  is  required  prior  to  having  a  complete  analysis  of 
this  step. 

3 .  Identify  Functions  to  address  the  Objectives  and  Constraints  - 
The  activities  within  IDEF  cover  the  CIM-OSA  Objectives  and 
Constraints  as  understood  by  the  assessment  team.  The  activity 
identification  process  within  IDEF  is  capable  of  identifying  the 
functions  that  address  the  Objectives  and  Constraints  within  CIM- 
OSA. 

4.  Identify  the  Object  Classes  required  by  the  Functions  -  CIM-OSA 
does  not  contain  all  of  the  object  classes  required  by  IDEF.  IDEF 
requires  Inputs,  Outputs,  and  Controls  classifications  as  opposed 
to  CIM-OSA  requiring  only  Inputs  and  Outputs  classifications. 

Interpretation  and  definitional  differences  may  exist  in  addition 
to  style  differences  between  the  two  methodologies'  Object 
Classes,  thus  requiring  additional  information  prior  to 
determining  a  match  or  mismatch  of  the  methodologies . 

5.  Define  the  Domain  Process  -  Both  methodologies  define  the  Domain 
Process  for  the  models  created,  but  IDEF  does  not  distinguish 
between  the  Domain  Process  and  the  Enterprise  Activity. 

Both  methodologies  have  a  required  scoping  activity  that  defines 
the  Domain  Process  for  each  model. 

6.  Define  the  Domain  Processes  Functional  Characteristics  -  The 
Functional  Characteristics  of  the  Domain  Process  in  CIM-OSA  are 
dynamic  in  nature  and  are  in  proper  form  to  be  simulated  with 
time  and  dependency  variables  included. 

IDEF  has  the  inherent  capability  to  provide  this  information  in  a 
functioning  format,  but  would  require  additional  syntax  in  order 
for  the  Inputs  and  Outputs  to  be  functional  in  nature.  This  is 
now  required  when  an  IDEF  model  is  being  prepared  for  simulation. 

7 .  Define  Domain  -  Both  methodologies  require  a  Domain  to  be 
defined.  The  IDEF  methodology  defines  the  Domain  through  a  Top- 
Down  approach,  with  the  Domain  being  defined  by,  and  within,  the 
A-l  Diagram.  CIM-OSA  defines  the  Domain  from  a  Bottom-Up 
approach . 

Although  the  methodologies  arrive  at  the  Domain  Definition  from 
opposite  directions,  they  both  do  require  a  definition  that  could 
and  should  be  very  similar. 


D-7 


8. 


Define  the  Domain  Relationship  -  CIM-OSA  requires  the  dynamics  of 
the  Inputs  to  be  included  in  addition  to  the  external 
environment.  This  includes  the  frequency  of  the  inputs  and 
dependency  relationships. 

IDEF  defines  the  external  environment  in  the  A-l  diagram  but  does 
not  define  or  identify  frequency. 

The  constraint  arrows  within  IDEF  would  need  to  be  quantified  and 
defined  as  flow  arrows  in  order  for  IDEF  to  fill  the  CIM-OSA 
methodology's  requirements  for  Domain  Relationship  definitions. 

9.  Define  the  Business  Process  -  The  decomposition  process  within 
IDEFo  defines  the  Business  Process  similarly  to  the  definition 
required  in  CIM-OSA. 

10.  Refine  the  Object  -Classes  to  the  Business  Process  _Level  -  The 
diagrams  within  IDEFo  show  the  Object  classes  at  the  Business 
Process  Level.  This  refinement  of  the  Object  Classes  meets  the 
requirements  of  CIM-OSA  as  understood  at  this  time. 

11.  Define  the  Business  Processes  Functional  Characteristics  - 
Similar  discussion  as  in  STEP  #6. 

12.  Identify  the  Enterprise  Events  -  CIM-OSA  requires  procedural 
triggers  or  events  with  related  and  dependent  results  as  its 
Enterprise  Events.  This  information  makes  the  model  event 
dependent  or  in  simulation  format. 

IDEF  does  not  include  dependent  events  as  arrows  as  required  in 
CIM-OSA.  In  order  for  IDEF  to  meet  the  requirements  in  CIM-OSA, 
additional  capabilities  would  have  to  be  built  into  the 
methodology . 

The  CIM-OSA  definition  of  Enterprise  Events  requires  additional 
clarification  prior  to  a  thorough  discussion  in  relation  to  the 
IDEF  methodology  by  the  assessment  team. 

13 .  Define  the  Domain  Process  Behavior  for  each  Enterprise  Event  - 
CIM-OSA  requires  a  dynamic  behavior  that  is  not  found  in  IDEFo  or 
IDEF1.  IDEF2  has  the  activation  rules  that  compare  to  the 
requirements  of  CIM-OSA,  but  IDEF2  has  been  shelved  and  replaced 
by  the  simulation  tool,  SLAM  II.  SADT  also  has  activation  rules 
in  place  that  may  meet  the  CIM-OSA  requirements,  but  stand-alone 
IDEF  does  not  have  this  capability  at  this  time. 

14.  Define  the  Enterprise  Activities  -  With  the  addition  of  call 
arrows,  IDEF  could  meet  the  requirements  of  CIM-OSA  with  respect 
to  the  definition  of  the  Enterprise  Activities. 

15.  Refine  Object  Classes  to  the  Enterprise  Activity  Level  -  Similar 
discussion  as  in  STEPs  #4  and  #10. 
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16.  Define  the  Enterprise  Activity  Functional  Characteristics  - 
Similar  discussion  as  in  STEPS  #6  and  #11. 

17.  Refine  the  Enterprise  Events  -  Similar  discussion  as  in  STEP  #17. 


18  Define  the  Business  Process  Behavior  for  each  Enterprise  Event  - 
Similar  discussion  as  in  STEP  #13. 


19.  Identify  the  Objectives  for  the  Enterprise  Activities  -  IDEF  data 
flow  analysis  identifies  flows  and  relationships  that  seem  to 
correspond  directly  to  the  requirements  for  Object  Views  within 
the  CIM-OSA  methodology. 

20.  Identify  the  Data  Elements  for  each  Object  -  CIM-OSA  decomposes 
the  Data  Elements  to  there  lowest  level  of  use  (the  entry  on  a 
form  vs  the  name  of  the  total  form)  for  each  Object. 

The  Data  Elements  identified  on  the  arrows  within  IDEF  are 
decomposed  no  further  than  the  identified  activities.  IDEF  could 
be  modified  to  require  this  extra  decomposition. 

The  decomposition  of  the  arrows  would  assist  in  the  assurance  of 
consistency  that  is  sometimes  lacking  in  IDEF.  The  decomposition 
is  covered  at  the  Entity  level  in  IDEF  instead  of  at  the  Element 
level,  as  required  by  CIM-OSA. 

DESIGN  PHASE 


21.  Assign  Design  Responsibility  -  Similar  discussion  as  in  STEP  #1. 

22.  Define  the  Alternative  Resources  to  Addreas._tiie.EA  Required 
Capabilities  -  CIM-OSA  requires  rate  and  usage  information  as 
part  of  its  resource  requirements.  Additionally,  information 
regarding  the  size  of  computing  resources  and  other  size  or 
amount  requirements  need  to  be  identified  in  CIM-OSA. 

Alternative  resource  requirements  are  also  required  for  CIM-OSA. 

IDEF  lists  only  the  types  of  resources  without  relation  to  size, 
quantity,  or  usage  rates.  Alternative  resource  requirements  are 
not  inherent  to  IDEF  and  must  be  added  through  the  use  of  ICAM 
SDM  in  order  for  IDEF  to  meet  the  requirements  of  CIM-OSA. 

23.  Define/Refine  EA's  based  on  Resources  Considered  -  Within  CIM-OSA 
is  a  decision  process  capability  which  can  change  the  Enterprise 
Activity  according  to  the  resources  available. 

IDEF  does  not  have  the  capability,  because  of  the  lack  of 
resource  definition,  to  apply  a  decision  making  process  that  can 
change  an  Enterprise  Activity. 
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24.  Define  the  Conceptual  Schema  -  With  the  addition  of  the  CDM 
implementation  tool,  IDEF  has  the  capability  to  define  the 
Conceptual  Schema  as  required  by  CIM-OSA. 

25.  Select  the  Resources  to  Address  the  EA  Required  Capabilities  - 
IDEF  does  not  show  or  identify  quantities  as  is  required  by  CIM- 
OSA.  IDEF  can  meet  the  CIM-OSA  requirements  when  SDM  is  used  with 
IDEF.  The  mechanisms  in  IDEFo  identify  the  resources  required  for 
an  independent  activity  but  not  the  quantity. 

26.  Define  the  Consistency  (Data  Integrity)  Constraints  from 
Consistency  Rules  -  IDEF  meets  the  CIM-OSA  requirements  partially 
by  offering  Cardinality  Rules  and  definitions/constraints  for 
Referential  and  Entity  Integrity.  Additionally,  BDM  offers  an 
Equivalence  of  Path  capabilities  during  modelling. 

(The  group  discussed  their  feelings  that  the  existing  IDEF  tools 
are  oversold  in  their  ability  to  maintain  Reference  and  Entity 
Integrity,  although  the  IDEF  methodology  accounts  for  the 
maintenance  of  integrity.) 

27.  Specify  New/Additional  Resources,  t.o  Address  .the  EA  Required 
Capabi lit ies  -  As  in  STEP  #s  22  and  25,  IDEF  offers  resources 
information  but  not  in  a  quantity  format  through  the  use  of  SDM. 

STEP  #s  22,  25,  and  27  need  additional  clarification  from  CIM-OSA 
prior  to  any  additional  analysis  between  IDEF  and  CIM-OSA. 

28.  Define  Functional  Operations  -  Similar  discussion  as  in  STEP  #s 
5,  9,  and  14. 

The  CIM-OSA  methodology  requires  actual  time  based  process  to  be 
identified  within  the  model. 

IDEF  requires  the  addition  of  Call  Arrows  in  order  for  it  to  be 
able  to  meet  the  CIM-OSA  requirements  of  showing  time  based 
functional  relationships. 

29.  Define  I/O  Volumes  for  each  Resource  Location  -  IDEF  does  not 
require  volume,  quantity,  nor  usage  when  identifying  Inputs  and 
Outputs . 

In  CIM-OSA,  the  resources  applies  may  dictate  the  activity  volume 
of  the  entity,  thus  requiring  volume,  quantity,  and  usage 
information . 

IMPLEMENTATION 

30.  Define  Implementation  Responsibility  -  Similar  discussion  as  in 
STEP  #  1. 

31.  Select  Products  to  Implement  the  Resources/Components  and  Define 
Implemented  Capabilities  -  STEP  #s  22,  25,  27,  and  31  may  include 
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an  extra  step  in  the  selection  and  specification  of  resources  for 
implementation  as  the  assessment  team  now  defines  them. 
Clarification  of  these  steps  is  required  prior  to  additional, 
meaningful  analysis  being  offered. 

IDEF  requires  additional  scope  to  meet  the  assumed  requirements 
of  CIM-OSA.  This  additional  scope  may  come  in  the  form  of  BDM's 
Strategic  Planning  Methodology  (SPM) ,  which  assists  in  the 
selection  of  resources/components. 

32.  Define  Data  Fragmentation  -  CIM-OSA  defines  and  identifies  where 
data  is  located  geographically. 

IDEF  is  does  not  offer  data  location  (distribution  of  data) 
identification . 

33.  Define  External  Schema  -  With  the  use  of  CDM  (from  IISS  program) 
as  an  implementation  tool,  IDEF  can  define  the  External  Schema  as 
required  in  CIM-OSA. 

34.  Define  how  the  Data  is  to  be  Stored  -  IDEF  does  not  cover  how  or 
where  data  is  stored  nor  the  communication  requirements  as  is 
required  by  CIM-OSA. 

35.  Select  Products  to  Implement  Data  Storage  -  Similar  discussion  as 
in  STEP  #  34. 

36.  Define  Communication  Requirements  -  Similar  discussion  as  in  STEP 
#  34. 

37.  Select  Products  to  Implement  Communication  Requirements  -  Similar 
discussion  as  in  STEP  #  34. 

38.  Define  the  Internal  Schema  -  Similar  discussion  as  in  STEP  #  33. 
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